Comments
3 comments
-
There is a known issue where check constraints are not recreated in scripts under the following circumstances:
1) The check constraints are named differently in the two databases,
2) The drop occurs because a function which the constraint uses needs to be altered.
If this is your problem, I'll add this thread to the bug report for that issue, and hopefully it will get fixed in the next point release.
If this doesn't sound like your problem - if you can send me (michelle.taylor@red-gate.com) the troublesome script folders (or snapshots or backups of the databases they were saved from), I'll see if I can work out what is going wrong here. -
The synchronization SQL generated when targetting a script folder is not reliable - we don't use it in the synchronization and it appears that it doesn't contain ALTER TABLE statements in this case.
The actual synchronization has nothing to do with the generated Synchronization SQL in the case of targetting a script folder, so the actual synchronization should be unaffected by any errors in the displayed Synchronization SQL. -
I am pleased to inform you that we have fixed this problem in the recently released SQL Compare V.7.
If you have a valid Support & upgrades option, you can download SQL Compare V.7 using the 'Check for updates' mechanism (SQL Compare GUI ->Help ->Check for updates)
or download using this link: HERE
SQL Compare V.7 will install along side any previous versions of the software.
Many Thanks
Eddie
Add comment
Please sign in to leave a comment.
I tried to compare two different database (one from live database and one from script folder) it does generate the correct tables and constraint. However, when I tried to compare two script folder its doesn't regenerate the constraint (it drop the constraint from the first database but not recreating it back).
I generate the script folder straight away from live database (using sqlcompare export as datasource menu)
Thanks,
Yongki