Options
What should happen in this case?
skuhn
Posts: 27 Bronze 3
During the course of development we have applied a foreign key constraint to an existing table and saved to source control. A week later we determined that the foreign key constraint should not be there so we removed it and again saved to source control. When we perform a compare against source control despite the fact that compare indicates that the tables are equivalent, the deployment script that is created still attempts to create the foreign key constraint. Everything has been checked into source control so it is unclear where it is even getting the information to create the foreign key, unless it is somehow following history. Even if that were the case there is no subsequent attempt to remove the constraints, which would leave the database in an incorrect state at the end of deployment.
We are using the latest version of SQL compare 10, against SQL Server 2005 databases and using Vault 5.0 for source control.
We are using the latest version of SQL compare 10, against SQL Server 2005 databases and using Vault 5.0 for source control.
Comments
Without more information it's impossible to work out what happened there. But if I were trying to figure it out I'd fist check the local copy of the source controlled folder and see if the constraint is still in the .sql file for that table.
If so, Vault must have some sort of problem. Do you use the Vault client to get the scripts or do you use SQL Compare's get latest from source control? Or do you tell SQL Compare to use a scripts folder rather than getting the latest from source control? If you manually get latest, do you then have the correct script?