DEFAULT Constraint issue in version 6.2.0.271
IronMike
Posts: 7
I have a nightly job that uses SQL Compare command line to compare script directories against databases. The job compares around 50 databases. Ever since I upgraded to version 6.2.0.271, the reports are erroneously marking tables as different when, in fact, they are the same. The difference it shows has to do with DEFAULT constraints. On the left side, it may show a column with DEFAULT ((0)), but the right side shows DEFAULT(0). It doesn't matter if I remove or add () from the table script - I still get the same result.
Can you please provide me with a download to the prior version of SQL Compare? Now that I have to manually examine 50 reports and edit 50 scripts, I am no longer able to keep up with my daily workload.
Thanks,
Mike
Can you please provide me with a download to the prior version of SQL Compare? Now that I have to manually examine 50 reports and edit 50 scripts, I am no longer able to keep up with my daily workload.
Thanks,
Mike
Comments
The difference that it's picking up isn't actually the default constraint difference that the viewer is showing - the viewer always shows that difference between different versions of SQL Server, it's a bug we need to fix with it, but that 'difference' doesn't cause objects to be actually marked as different.
Could you tell us what SQL Compare tells you it's doing to them to make them equal when you try to run a synchronization of one of these tables? Or perhaps even supply us with backups/snapshots of the offending databases so we can see the difference for ourselves? (My email address is michelle.taylor@red-gate.com if you want to do this.) Hopefully we can fix whatever bug has suddenly started coming up with differences for you, so you can keep using the latest version.
Redgate Software
Thanks,
Mike
If you need more information, please let me know.
Thanks,
Mike
We also found a problem with statistics in that SQL Server reports a filegroup for them (the table filegroup) and this was interacting with the above problem to cause SQL Compare to think that the statistics were different.
Fortunately it looks like you've found a workaround. The fixes for this problem will be in the next release of SQL Compare, but currently we're still actively working on the development branch they're fixed in, so we'd rather not hand out private builds unless you really need them.
Redgate Software
Thanks,
Vladimir
Some of the known problems that are causing this: if your filegroups have different capitalisation in different databases, we still report a difference even though case sensitivity is off; statistics report themselves as on a filegroup but this is never actually used so we don't display it anywhere but we still compare on it.
You can try setting case sensitivity on (which should at least show you the difference if it's filegroup case differences), and setting 'ignore statistics' on (which will solve the problem if it's statistics filegroups).
If neither of these help, I'll look into it further (you might have found a different problem entirely).
Redgate Software
Thank you,
Karl
Redgate Software