Migration scripts version 2 is a feature of SQL Source control and Red Gate’s various database deployment products, such as SQL Compare. This is how Red Gate handles those tricky database deployment scenarios that traditional database diff tools struggle with. For example table renames, adding new NOT NULL columns and making changes to the data within a database. In this scenario I’ll discuss the problem of deploying a table re-name from some source to a persistent SQL Server database that contains data.
Version Script
1 …
2 …
Migrations v2
Source Target
Version Script
1 …
2 …
3 …
4 …
Alex Yates
Red Gate adds a table value function to the database and this contains information about custom upgrade scripts that need to be executed prior to SQL Compare. These upgrade scripts are normally written by humans, specifically to cover the scenarios that diff tools, such as SQL Compare, can’t handle. You’ll see in this example that the source database contains four migration scripts, but the target database only has the first two.
Version Script
1 …
2 …
3 …
4 …
Migrations v2
Source Target
Version Script
1 …
2 …
3 …
4 …Step 1
1.Deploy and execute migration scripts
Alex Yates
The first step to deploy this database, therefore, is to copy across scripts three and four and execute them against the target database.
Version Script
1 …
2 …
3 …
4 …
Migrations v2
Source Target
Version Script
1 …
2 …
3 …
4 …
1.Deploy and execute migration scripts
2.Use SQL Compare to deploy remaining changes
Step 1
Step 2
Alex Yates
Now we should be in a position where it is safe to let Red Gate’s SQL Compare engine work out the remaining changes to complete the deployment.
Version Script
1 …
2 …
3 …
4 …
Migrations v2
Source Target
Version Script
1 …
2 …
3 …
4 …
1.Deploy and execute migration scripts
2.Use SQL Compare to deploy remaining changes
Step 1
Step 2
BEGIN TRANSACTION
COMMIT TRANSACTION
Alex Yates
Naturally, the entire process of deploying migration scripts and SQL Compare generated scripts is all wrapped into a single transaction in a single script. This means that the script can easily be reviewed by a DBA prior to deployment and it ensures that if there are errors during any part of the script the entire deployment will be rolled back. Let’s take a look at an example migration script…
Migrations v2
Example migration script
IF some condition
BEGINEXEC some scriptEND
Alex Yates
We start any migration script with a guard clause. This protects us from ‘database drift’, that is changes that occur outside of our normal process. Assuming the guard clause is satisfied the remaining part of the script will be executed. You could write whatever T-SQL you choose in this part of the script so whatever your task, if you can express your task in T-SQL on the target DB you can deploy it using migrations v2.
Migrations v2
Example migration script (renaming MyTable to MyTable2)
IF @ShouldRunMigrationScript = 1BEGINEXEC sp_renameEND
Alex Yates
In this scenario our challenge is to deploy a table re-name. You can see in this version of the script that in my guard clause I’m checking to see if the old version of my table exists on the target database. Assuming that the table with the old name exists I will then execute sp_rename to handle the change.
Migrations v2
Example migration script (renaming MyTable to MyTable2)
IF NOT EXISTS (SELECT 1 FROM [information_schema].[Tables] WHERE table_schema = 'dbo' AND TABLE_NAME = ‘MyTable')BEGIN SET @ShouldRunMigrationScript = 0; PRINT 'Object ''[dbo].[MyTable]'' could not be found - skipping migration.';END
IF @ShouldRunMigrationScript = 1BEGINEXEC sp_rename '[dbo].[MyTable]', 'MyTable2'END
Alex Yates
Here is the full version of my migration script. By using the guard clause I protect myself from the scenario where the table has already been renamed by someone else. This is important because if the table has already been renamed the sp_rename would fail.As it happens, since table renames are one of the most common scenarios where migration scripts are needed, Red Gate SQL Source Control is now smart enough to detect table renames by itself and it will prompt you to add a migration script. What’s more, in this scenario it will generate the migration script for you automatically.
Version Script
1 …
2 …
3 …
4 …
Migrations v2
Source Target
Version Script
1 …
2 …
3 …
4 …
1.Deploy and execute migration scripts
2.Use SQL Compare to deploy remaining changes
Step 1
Step 2
BEGIN TRANSACTION
COMMIT TRANSACTION
Alex Yates
In summary, migrations v2 allows us to work on our databases declaratively and deploy whatever changes we choose. We only need to maintain upgrade scripts for the scenarios where they are actually required. This helps us to get the balance right between using computers to manage the easily automatable tasks while keeping a human in the loop specifically when needed to script out the more complicated parts of the deployment based on their knowledge, experience and judgement.
