The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

Troubleshooting Schema Compare Issues

You might encounter the issues in this topic when you compare two database schemas.

To generate the correct order of objects in an update script, Schema Compare examines object dependencies. For example, if a view depends on a table, the table must be created before the view. If the object that depends on the second object does not use a schema-qualified name, the dependency might not be identified and the update or creation script might have statements in an incorrect order. This discrepancy can result in errors when you update a target to match a source or deploy changes to a database. This issue also applies to database build scripts.


To work around this issue, make sure to schema-qualify the names of objects that are involved in dependent relationships. In the following example, you can guarantee that the dependency will be correctly identified if you change the end of the statement to reference [dbo].[KeysTable] instead of just KeysTable:

CREATE VIEW [NewUser].[ViewReferencingScalarFunction] AS SELECT Column2, dbo.SimpleMultiplyParamByTwo(PK_Column) AS [Function] FROM KeysTable

In Team Edition for Database Professionals, you cannot create symmetric keys, asymmetric keys, or certificates as database objects. When you import a database schema, placeholder comments are put into the pre-deployment script with the names of the keys and certificates. You must edit the pre-deployment script to create those objects. Similarly, when you compare database schemas, the Schema Update Script does not contain the necessary Transact-SQL (T-SQL) commands to create missing symmetric keys, asymmetric keys, or certificates. You must export the update script to the editor and add statements to create those objects.

Schema Compare does not compare or script options that are set using the sp_tableoption or sp_indexoption. There is no workaround for the issue.

If you receive a timeout error when you compare the schemas of large databases, you might need to increase the timeout value. This option is not exposed through the user interface. You must modify the QueryTimeoutSeconds value that is stored in the registry under HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\DBPro\Databaseand specified in seconds. By default, the timeout is 60 seconds.

If a filegroup in a target database is read-only, that property will always appear as a difference in a schema comparison between that database and a database project. In addition, the primary filegroup is ignored when you compare schemas.

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2014 Microsoft