The combination of technical and cultural processes behind databases makes automation difficult. Databases has a state associated with them, so you cannot blow them away like application code and create again from scratch without losing the data. Managing change in a way that doesn’t impact the data is very problematic. Combine that with the cultural issues, the silos, it creates a really difficult problem. There are some general best practices that you can apply to tackle a lot of this complexity, but any time you try to design the solution and get into the technicalities, a lot of time you end up implementing something very specific to a particular type of database. In this blog post, we’ll learn how to use SSDT to implement continuous integration and deployment for SQL database Schema to take some of these worries away.
I don’t do this a lot since most of the apps are now a days using Azure SQL using all the benefits it offers. So I thought it would be better to take note of all the steps done for this. If the msdb database is damaged and you do not have a backup of the msdb database (for whatsoever reasons), you can create a new msdb by using the instmsdb script. In this blog post, we’ll go through steps required for the same.
Rebuilding the msdb database using the instmsdb script will eliminate all the information stored in msdb such as jobs, alert, operators, maintenance plans, backup history, Policy-Based Management settings, Database Mail, Performance Data Warehouse, etc.
The task is used to deploy Azure SQL Database to an existing Azure SQL Server, either by using DACPACs or SQL Server scripts. The DACPACs are deployed using SqlPackage.exe and the SQL Server scripts are deployed using the Invoke-Sqlcmd cmdlet. DACPACs and SqlPackage.exe and Invoke-Sqlcmd cmdlet provides for fine-grained control over the database creation and upgrades, including upgrades for schema, triggers, stored procedures, roles, users, extended properties etc. Using the task, multiple different properties can be set to ensure that the database is created or upgraded properly. Continue reading “VSTS Azure SQL Database Deployment task keeps failing with Error: Login failed for user”
If while working on Azure SQL PaaS or even on-premise SQL database, you are stuck with this error “Index was outside the bounds of the Array. (Microsoft.SqlServer.smo)”, the most likely reason is that the version of SQL server management studio on your local machine is on the lower version that the SQL server version on the server end.
In such a scenario, you would need to upgrade the SSMS version installed on your local machine. Apparently, the reason behind the error message is that SQL couldn’t show new features in your old SSMS version. Continue reading “SQL Error : Index was outside the bounds of the Array (Microsoft.SqlServer.smo)”