How to: Use Schema Compare to Compare Different Database Definitions

 

SQL Server Data Tools (SSDT) includes a Schema Compare utility that you can use to compare two database definitions. The source and target of the comparison can be any combination of connected database, SQL Server database project or snapshot or .dacpac file. The results of the comparison appear as a set of actions that must be taken with the target to make it the same as the source. Once the comparison is complete you can update the target directly (if the target is a project or a database) or generate an update script that has the same effect.

The differences between source and target appear in a grid for easy review. You can drill into and review each difference in the results grid or in script form. You can then selectively exclude specific differences.

You can save comparisons either as part of a SQL Server Database project or as a standalone file. You can also set options that control the scope of the comparison and aspects of the update. Then you can save the comparison so that you can easily repeat the same comparison later or use it as the starting point for new comparison.

The following procedure compares the schema of a database project with a connected database.

Warning

If a project is specified as the target for comparison, the maximum supported path length (excluding drive letter, colon and leading backslash) for the project is 256 characters. If your project path exceeds 256 characters, you will still be able to compare its schema with a database or another project. However, you will not be able to update its schema.

Warning

The following procedures utilize entities created in previous procedures in the Connected Database Development and Project-Oriented Offline Database Development sections.

To compare database definitions

  1. On the SQL menu, select Schema Compare, and then click New Schema Comparison.

    Alternatively, right-click the TradeDev project in Solution Explorer, and select Schema Compare.

    The Schema Compare window opens, and Visual Studio automatically assigns it a name such as SqlSchemaCompare1.

    Two drop-down menus with a green arrow in between them appear just below the Schema Compare window toolbar. These menus allow you to select database definitions for your comparison source and target.

  2. In the Select Source drop-down, choose Select Source and the Select Source Schema dialog opens.

    Notice that if you opened the Schema Compare window by right clicking the project name, the source schema is already populated and you can proceed to step 4.

  3. Select the Project radio button, and then select the TradeDev database project you have created in the previous procedure.

  4. From the Select Target drop-down in the Schema Compare Window , choose Select Target, and the Select Target Schema dialog opens. In the Schema section, click the Database radio button, then click the New Connection button.

  5. In the Connection Properties dialog box, enter the server name where the TradeDev database resides and make sure that correct authentication credentials are provided. Then select TradeDev in Connect to a database and click OK.

    You can also click the Options button in the Schema Compare Window toolbar to specify which objects are compared, what types of differences are ignored, and other settings.

  6. Click the Compare button in the Schema Compare Window toolbar to start the comparison process.

    When the comparison is complete, the structural differences between the project and the database appear in the Results pane in the upper part of the window. By default, the comparison results group all the differences are grouped by action (such as Delete, Change, or Add). The Results pane displays a row for each database object that differs between the database definitions. Each row identifies the object in the source or target schema (or both) and the action that will be taken on the target schema to make the target object the same as the source object. If an object has been refactored and either renamed or moved to a new schema, the source and target names are different and the source name appears in bold font to highlight the difference.

    By default the results list hides objects that are the same in both schemas or that are not supported for update (for example, built-in objects). You can click on the appropriate filter buttons in the tool bar to show these objects.

    To change the grouping preference, click the Group Results dropdown list in the toolbar. Select Type to group the results by object type (for example, by tables, views, or stored procedures).

  7. Find the Products table in the Tables group. Click on the row and notice that the source and target definitions of the table appear in the Object Definitions pane with the differences highlighted. You can also expand the Products table row in the Results pane to inspect the specific elements in the table that are different.

  8. By default all differences are included in the scope of the Update Target action. You can exclude differences that you do not want to synchronize. To do so, uncheck the in the Action column in the center of each row. Alternatively, right-click a row in the Schema pane, and select Exclude. Notice that the row is immediately grayed out. When it is time to update the target database, this row will not be considered for any pending changes.

    You can also right-click on a group row and select Exclude All or Include All, which is equivalent to unchecking or checking all differences in that group. When you group results by schema this is a useful way to include or exclude all changes to a specific schema.

    Warning

    If the row being excluded has any dependent objects (for example, a Table row that is referenced by a View row), the excluded row is disabled but its checkbox is not cleared. Once all rows that depend on it are unchecked, the disabled row will be unchecked. In addition, if a row is refactored (renamed or moved to another schema), then the checkbox is disabled for that row and any of its dependent child rows.

    Notice that if you refresh the comparison, those differences that you have chosen to skip will be ignored.

To update the schema of the target, you have two choices. You can update the target directly from the Schema Compare window if the target is a database or project, or you can generate an update script if the target is a database or a database file. A generated script appears in the Transact-SQL Editor, from which you can inspect the script execute it against a database. The following procedures describe these options further.

Warning

The update will fail because our change involves changing a column from NOT NULL to NULL and as a result causes data loss. If you want to proceed with the update, click on the Options button (the fifth one from the left) on the toolbar for the Schema Compare and uncheck the block incremental deployment if data loss option.

To update directly in the Schema Compare window

  1. Click the Update button on the toolbar for the Schema Compare window.

  2. Examine the change script generated. You can save the script by using the File/New menu. This can be handy for situations when you are not authorized to update a production database, in which case you can give the script to a DBA for deployment later.

  3. If you have the necessary permission to update the database, click the Execute Query button in editing pane toolbar to run the script.

To update by script

  1. Click the Generate Script button (the fourth one from the left) on the toolbar for the Schema Compare window.

    The generated script appears in a new Transact-SQL Editor window

    Warning

    Only .dacpac files produced by the SSDT snapshot process support this behavior. You cannot target a .dacpac file produced by the SQL Data-tier Application (DAC) tools or framework at this time.

  2. Examine the generated change script. You can save the script by using the File/Save or File/Save As menu command.

    A saved script can be handy in situations when you are not authorized to update a production database. In these cases you can give the script to a DBA for deployment later.

    Alternatively, you can connect the Transact-SQL Editor to an appropriate server and execute the script directly. Before you can perform this procedure you must have the necessary permission to create or update the database. If you have the necessary permission to update the database, click the Execute Query button in editing pane toolbar to run the script.

  3. Click the Connect button. This action either connects to the current server or prompts you to enter or select a in on the Connect to Server dialog. Notice that the database name is defined in the script as a command variable.

  4. Inspect the script and, if necessary, make any changes to the command variables that define the target database name and associated prefix and the file paths.

  5. Click the Execute button in the editing pane toolbar to run the script.