prevent unique constraint from being scripted?

austrianfoodispuke

I am creating a script that will drop database objects.

However, it is including unique constraints in the script.

The problem is, the next time the database is created, the constraints are different and the DROP script fails

How do I fix this?

James B

Can you give a little more detail on what's happening here...

How are you creating the script? Is this via SQL Compare from a DB with the objects to a DB without? There are options in Compare to ignore constraints and keys and so on, but it's difficult to know if this will help you without a more defined example of the problem.

austrianfoodispuke

I have a database.
I have an empty folder.

I compare the database to source control i.e. the empty folder

All the scripts are created and work correctly.
i.e. the database's objects are correctly dropped

However
If I recreate the database using scripts, then the DROP script no longer works due to unique constraints that have been scripted for dropping.

I have tried various 'ignore' checkboxes but still the unique constraints are scripted for deletion

Am using SQL Compare 8.5.12.20 against sql server 2005

James B

I'm not sure there is an easy way to work around this issue with Compare unfortunately.

Generally, the recommendation appears to be to specify your constraint names to avoid this issue occurring (see here: http://www.sqlservercentral.com/articles/Naming+Standards/sysgenconstraintnames/765/)

Although SQL Compare has an ignore option for constraint names, this only affects the comparison stage - meaning that if you tick the option and the only difference between two tables is the constraint, then the objects won't be seen as different. However any other change (which leads to the object getting scripted as a difference) will still include the constraints. There isn't a way to exclude them from the sync step.