Microsoft Visual Studio Team System 2008 Database Edition (aka “Data Dude”) provides tools for managing and deploying SQL Server databases.
In our last tutorial, we described how a database developer would use the Schema Compare tool to update a database project with changes to a SQL Server database.
This article describes how to use the Schema Compare tool to push those changes out to a different SQL Server database. There are two scenarios where you would do this.
In Scenario 1, a developer has a local copy of the development database and wishes to get the latest updates to the database.
In Scenario 2, a database administrator (DBA) or build master who is charged with migrating database changes from one environment to the next. Just as .Net and web code gets regularly migrated from a development environment to a QA or Production environment, database object code must also be migrated, and that migration generally must be kept in sync with all code that depends on those database objects.
We start this process by launching Visual Studio and opening the database project. If a source code repository such as TFS is used, we need to get the latest code from the repository.
The database to which we wish to write the changes is known to Data Dude as the “target database”. We need to make sure that a connection exists in Visual Studio to the target database. This is a one-time step and you can use the Server Explorer (View | Server Explorer) to create a connection.
The following steps describe how to propagate changes to the database.
1. Launch Visual Studio and open the database project. Get the latest source code from your source code repository.
3. Under Source Schema, select the Project radio button and select your database project from the dropdown list.
4. Under Target Schema, select the Database radio button and select the connection to your database from dropdown list.
6. The Schema Compare window lists every object that exists in either the database or the database project. The objects are grouped in folders by object type (Tables, views, stored procedures, etc.) You can expand or collapse a folder to view or hide objects of that type. The important column is “Update Action” which describes what will happen if you write the updates to the target.
a. Objects that exist in the source (the project) but not in the target (the database) were likely recently added after the last synchronization. By default, the Update Action will be “Create” meaning the object will be created in the target database.
b. Objects that exist in both the source and the target will have an Update Action of “Update” if they have been modified in the database since the last synchronization or “Skip” if they have not.
c. Objects that exist in the destination (the database) but not in the source (the project) were likely dropped after the last synchronization. By default, the Update Action will be “Drop” meaning the object will be removed from the database.
7. On a database with many objects, it is useful to view only the objects that have changed since the last synchronization. To do this, click the Filter toolbar button and select Non Skip Objects.
8. If you wish, you can modify the Update Action on objects by selecting the dropdown in the “Update Action” column. Some actions are grayed out because Data Dude will not allow you to perform any action that would violate referential integrity rules.
9. After you have set the “Update Action” of every object appropriately, you have a couple options.
a. You can migrate your changes immediately to the target database by clicking the “Write Updates” toolbar button. Click Yes at the confirmation to write the updates to the database project.
b. Alternatively, you can export your changes to a SQL script by clicking the Export To Editor toolbar button. This will create a single text file containing SQL script that you can run from a query window of SQL Server Management Studio. This is useful if you need to make changes to the script prior to executing. I have used this technique when my database contains views or stored procedures that refer to remote servers and I want to modify the name of the server before migrating the object.
Alternatively, you can deploy changes from a database project to a database by “Deploying” the project (select Build | Deploy Solution). This deploys your changes using the settings found on the Build tab of the project properties page. This method requires fewer steps, but it is less flexible than the method described above. In particular, it does not allow you to select which objects are deployed or export and modify the script of database changes.
In the next article, we will discuss how to use Data Dude to write Unit Tests against SQL Server stored procedures.