Understanding the comparison results
Published 21 August 2019
Objects with different owners or schemas
Objects that are the same but have different owners or schemas are treated as different objects. For example, if a stored procedure exists in both databases and is identical except for its owner, it is considered to be a completely different object.
If you want to compare objects that are the same but have different owners, you can remap the owners when you set up your comparison project.
Object-level permissions
When you connect to a database for which your user is not the database owner, SQL Compare displays only those objects for which you have been granted permissions. In addition, the SQL Differences pane will display only the object-level permissions for the authenticated user; other users' permissions will not be displayed.
If a permission is given using WITH GRANT OPTION (for example GRANT SELECT ON <objectname> TO <username> WITH GRANT OPTION) it will not be recognized. Permissions assigned that do not use WITH GRANT OPTION are detected.
For more details, see Permissions required to use SQL Compare.
Extended stored procedures
SQL Compare does not compare extended stored procedures.
Encrypted database objects
You have the option to decrypt text objects databases created using the WITH ENCRYPTION option.
Disabling this option can result in faster performance. To disable this option, on the Options tab of the Project Configuration dialog box, clear the Decrypt encrypted objects check box.
When this option is disabled, SQL Compare can't compare the encrypted objects, or display their creation SQL scripts, and can't deploy them.
If an encrypted object which can't be decrypted exists in both databases, it is shown under the objects that exist in both but are different group in the comparison results in the main window (select Type of Difference in the Group by box to arrange objects by difference). SQL Compare can't compare the encrypted objects, or display their creation SQL scripts, and can't deploy them.
Certificates, symmetric keys, and asymmetric keys
SQL Server severely restricts access to certificates, symmetric keys, and asymmetric keys. Consequently, SQL Compare can't compare all of the properties for a symmetric key.
To ignore all certificates, symmetric keys, and asymmetric keys in the deployment, on the Project Configuration dialog box, select the project option Ignore certificates, symmetric and asymmetric keys.
Replication
SQL Compare does not compare stored procedures that have been created for replication.