How can we help you today? How can we help you today?
Michelle T
The script you've provided there is the script that Compare generates when it hasn't actually generated any actions to synchronize between databases, so this does look like a bug (Compare shouldn't produce just that script because if it's producing a synchronization script it should be generating some actions). I've just tried out saving some tables with extended properties on to snapshots and scripts, and comparing the results to each other, and it's working fine for me. Can you give me more information about the tables and extended properties? You can email more information to michelle.taylor@red-gate.com if you don't want to post it on a public forum. (What would be most useful is a copy of the full creation script for those two tables, but other useful information would be whether the extended properties are directly on the table or on a column, constraint, index or trigger, what data type the value of the extended properties has, and anything interesting about the table like computed columns or complex constraints or triggers - it might be that the problem is in fact with another element of the table, but the SQL Difference pane's textual comparison is getting confused amongst the extended properties instead of reporting the real problem.) / comments
The script you've provided there is the script that Compare generates when it hasn't actually generated any actions to synchronize between databases, so this does look like a bug (Compare shouldn't...
0 votes
Constraints added inline (i.e. in a table) ought to be recognised as identical to constraints added via ALTER TABLE. There are a couple of things that might be causing them to look different: 1) The constraints will come up as different in the Difference Viewer pane at the bottom of the comparison window, because that just does a textual comparison (for speed reasons) rather than a full semantic comparison. The comparison determining whether the objects are marked as different in the main comparison window is much more sophisticated than the one run by the difference viewer. So if you have any other differences on that table, that might be the cause. 2) If either of the constraints are not given a name in the script, Compare will generate a random name for them in the same way that SQL Server would, but it is quite likely that it will generate different names for the two different constraints. Turning on the option 'Ignore Constraint and Index Names' or naming the constraints explicitly in the scripts will stop this showing up as a difference. (Unfortunately it is impossible to guess what name SQL Server will give an unnamed constraint before the script is run into a live database... it will be different if you run the script into the same live database twice.) If it is neither of these, you may have succesfully found a bug :oops: and we'd like some more details on what these constraints look like so we can reproduce it... / comments
Constraints added inline (i.e. in a table) ought to be recognised as identical to constraints added via ALTER TABLE. There are a couple of things that might be causing them to look different: 1) Th...
0 votes
The release version of Compare 6 will definitely support reading a directory structure recursively for script files, rather than just reading a flat single directory as the Beta version does. / comments
The release version of Compare 6 will definitely support reading a directory structure recursively for script files, rather than just reading a flat single directory as the Beta version does.
0 votes