I think this is the sort of thing that you would have to sort out manually. SQL Compare has an "ignore names on constraints" option but I believe that works on the comparison and not on the synchronization.

This is now happening on another database of ours with a different table and constraint. Are you sure that there is no solution for this? I can't believe that our only solution would be to wait for someone to get this error, then have to go in manually and delete the constraint and then ask them to re-convert their database.

It is very hard to fix this programmically. SQL Server does not let you directly delete records out of the default constraints table (sys.default_constraints). You have to do a ALTER statement on the table. The problem with that is that we don't know what table it is under until the error happens. I have been able to write a query that looks up the table name:

And then I have to see how hard it would be to put that into a drop statement and have that run before the structural comparison. Even if this all works...someone else can call in the next day with a new constraint that's giving them issues and I would have to write a new query with drop for the new constraint name.

This has been brought up with our development team (sc-6104) - it should only happen in the rare circumstance where you rename tables and trip over system-generated constraint names (that contain parts of the new table names). At some point in the future, SQL Compare will finally support "re-runnable" scripts that do these checks, but for now, unfortunately you have to try to fix bits of the information schema manually.

I have found your product does not like constraints very well. I had several constraints fail in a comparison of a development and a test database whereby we introduced (2) column changes ( additions ) and (3) view changes, and 4 procedure changes to support new columns. The offending columns were not related to the changes either. Just happened to be columns with constraints.

The only circumstance where I was able to reproduce this behavior was when I generated a sync script by comparing two databases, and running it on a third "similar" database. This happened because SQL Server names the default constraint in a predictable way.

If you are not running the generated script against a database that was not part of the original comparison, please let me know, so we can proceed with your support ticket (F0070615) and we can get some more information from you, because it would be unlikely that this problem has the same cause as the one mentioned in this forum topic, and you're having a new, as yet unknown, problem.