Comments
7 comments
-
Hello,
Thanks for reporting this! We are aware of this bug and have a fix in the pipeline which should be included in the frequent updates release next week. If this doesn't solve your problems please let us know!
Sorry for any inconvenience.
Thanks,
Asha -
When will this bug be addressed. It's preventing me from using SQL Compare with this database, even for the tables which are not temporal. I get an error when trying to generate a script for the "normal" objects too.
-
Hi,
The fix for this was released in January so if you update to the most recent SQL Compare version this should be fixed.
If you're still having issues, please let us know!
Thanks,
Asha -
I am currently using version 13.1.8.5525 (latest version) and I still have the exact same problem.
-
Hi David,
Apologies, it seems the bug fix hasn't made it to the main release yet. If you go to "Help" > "Configure frequent updates" and check the box, then go to "Help" > "Check for updates" you should be able to download version 13.2 of SQL Compare which should contain this fix.
Alternatively, the fix should be included in the next main release which will be released early next week.
Please let us know if any problems persist!
Thanks,
Asha -
I just upgraded to 13.2 and it behaves the same way. It is still defective.
-
Hi @DavidStein
This looks like a question that one of Support engineers will need to investigate for you.
If you've a got support contract, please send us a ticket. Provide as much information as you can - screenshots of any errors, log files etc – so we can help you as fast as possible.
If you're not covered by a Support contract at the moment, email our Sales team at sales@red-gate.com, and they'll be able to help.
Add comment
Please sign in to leave a comment.
The following example is from one of the simplest tables.
Notice that the history table schema is dbo. SQL Compare has now decided that it should be lkp like it's parent table. The deployment script bears this out: