Comments
Sort by recent activity
7.1.0.245 Professional Editional
When creating comparison projects, I map tables, manually set comparison keys, save, and hit "Done" to compare.
SQL Compare indicates no tables could be compared -- nothing was saved!
I then repeat all the mapping and setting of comparison keys, hit "Done" again, and it works.
But when I reopen such a project, everything is lost again -- none of the mapping or comparison keys are retained.
Does v8 correct this incredibly time-wasting issue? Will v8 be released soon?
Thank you much. / comments
7.1.0.245 Professional Editional
When creating comparison projects, I map tables, manually set comparison keys, save, and hit "Done" to compare.
SQL Compare indicates no tables could be compared --...
I alsorequest support for custom extended properties.
The ability to add additional named extended properties can be very valuable, not only in defining structured documentation, but also as tools for change management to control what gets deployed to various environments.
And for a tie-in to another great RedGate tool, SQLCompare Pro could even be enhanced to use extended properties for automatically filtering what gets scripted -- i.e., include only objects where "Include_In_Build" = "True" or exclude objects where "Exclude_From_Build" = "False". / comments
I alsorequest support for custom extended properties.
The ability to add additional named extended properties can be very valuable, not only in defining structured documentation, but also as tools ...
Don't count on SQL Compare Pro as a workaround. I'm getting the
"failed to locate the target table" error in SQL Compare Pro.
This is happening to me on several tables. It's rendering SQL Compare Pro unusable for source control (the whole reason for buying Pro).
Environment: Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (X64) Standard Edition (64-bit) on Windows NT 6.1 <X64> (Build 7600: )
Failures all occur on foreign keys for tables in a schema other than dbo, and referencing tables in that same (non-dbo) schema.
sherr wrote:
There's another situation that could cause this issue. It could happen if you commit an object, but do not commit its dependencies. This causes the version in source control to be in an invalid state, which we then have trouble parsing. You should be warned if there are dependencies when committing or getting and it is checked by default to include these.
Creating a new db and relinking does NOT help in this case.
WORKAROUND:
1) If you don’t have a lot of history in source control that you care about since this is an evaluation, then it might be better to just DELETE everything in source control and start again. This time when you commit an object, include its dependencies and hopefully you will get pass this issue.
2) If you want to keep your current history, do you have SQL Compare Pro? If so, you could script TableA to a scripts folder and then commit this to the Tables directory in SVN using TortoiseSVN. This should put the source control version back in a “valid†state and let you continue. If you don’t have SQL Compare Pro, script out the table using SSMS, and then Commit to SVN, but make sure it is named owner.tablename.sql like the other files are named.
/ comments
Don't count on SQL Compare Pro as a workaround. I'm getting the
"failed to locate the target table" error in SQL Compare Pro.
This is happening to me on several tables. It's rendering SQL Compare ...