Activity overview
Latest activity by bjones
I would like to disagree with the last posting. I am currently evaluating SQL Compare 6.2.0.271, and have experienced the same problem described by the other posters. In fact, I have just reproduced it in a way that I believe your developers can reproduce.
Pick a database to do comparisons on. Export that database to a script folder. Make a direct comparison between the database that you just exported and the script folder (turn off all setings to ignore schema differences). In my case, the comparison, which should show no differences, shows differences. Those difference all appear to be in the formatting of the DEFAULT constraint on columns, where the difference is 2 pairs of parens instead of one.
Take that same database used in the above paragraph and export it to a snapshot. Make a direct comparison between the database that you just exported and the snapshot (turn off all setings to ignore schema differences). This time, the difference report will show no differences.
In addition, if I go to my scripts folder, I will see that the actual exported scripts do not have the 2 pairs of parens, but just one. So it appears that the engine that reads the files and prepares for the differencing is actually adding the extra pair of parens in. What might be going on here? Is there a way for a user to change how the engine is interpreting the scripted files?
I really like the product and hope that this can be fixed in future versions!!
Thanks!!
bjones / comments
I would like to disagree with the last posting. I am currently evaluating SQL Compare 6.2.0.271, and have experienced the same problem described by the other posters. In fact, I have just reprodu...