User profile for Chris_F

Hi, I have added to the uservoice site, also thanks for your suggestion of your other tools too. The main reason for my particular use case is that the deployments are often done by clients where we have no access to their database, network or even direct contact with their sql engineers. It's completely hands-off. Also there is some data manipulation done as well. This leads us to having release cycles where code changes and database changes are scripted into our source control as part of the release process. / comments

Hi,I have added to the uservoice site, also thanks for your suggestion of your other tools too.The main reason for my particular use case is that the deployments are often done by clients where we ...

0 votes

Hi, please delete this post. On further investigation the bug was caused by a conflict with a 3rd party tool and not a red-gate product. / comments

Hi, please delete this post. On further investigation the bug was caused by a conflict with a 3rd party tool and not a red-gate product.

0 votes

I have tested and this still occurs in 9.1.5.4619. Have submitted a support request, as well as created a video of it happening. / comments

I have tested and this still occurs in 9.1.5.4619.Have submitted a support request, as well as created a video of it happening.

0 votes

If that fixed it then that definitely should be a bug. White-space should be classed as the white-space around statements, not within a literal string. If a statement is preceded with 2 tabs instead of one that's no issue, but if there is a string/code different then that is a major issue if it gets missed. SQL Compare should be smart enough to pick up the difference between the two. / comments

If that fixed it then that definitely should be a bug. White-space should be classed as the white-space around statements, not within a literal string. If a statement is preceded with 2 tabs instea...

0 votes

Sam, I think the existence check is the incorrect approach, I think that's possibly even worse than a script crash. Assuming the case of the proc was changed, and also some important code was changed in the content - if the user chose to deploy that script by 'ticking add' and the existence check was enabled, the script would pass and they would assume the code has been deployed when it hasn't been. At least with a crash, you know there is an issue to take action. In terms of the collation I think that's ok. Assuming that most (if not all) cases two objects with the same name is assumed to be the same object, including with scripts. Unless there is a specific collation to forbid that, I think that's ok to treat it as a rename by default. If you're worried about that then perhaps create a user option telling the product how to treat case-differing objects - with the default being a rename. On the balance of probabilities I'd say less than 1% of cases would require 2 independent objects of differing cases. / comments

Sam, I think the existence check is the incorrect approach, I think that's possibly even worse than a script crash. Assuming the case of the proc was changed, and also some important code was chang...

0 votes

Hi @sam.blackburn , As I have mentioned in support request - I believe this approach is incorrect. If you tick both add/delete then everything works fine. If you tick add (and not delete - some people ignore deletes as they are destructive), then the resulting script will crash and return an "already exists" error. Renaming the case (name) of an object is a single operation. In theory, I should be able to click all new, all changed, no deletes and have the script work without failure. The add can't ever work without the delete being run first (it will always do CREATE and not ALTER) - so they are one in the same option. (Sorry for hijacking the original meaning of thread) / comments

Hi @sam.blackburn , As I have mentioned in support request - I believe this approach is incorrect. If you tick both add/delete then everything works fine. If you tick add (and not delete - some peo...

0 votes

Actually I've found the issue (for my problem at least). Half my fault, half app's fault. Issue was "case sensitive comparison" is turned on. * When comparing with snapshot it incorrectly shows databases as identical and doesnt pick up that there is a case sensitive rename * When comparing with a database it shows as an add / drop instead of an alter (rename) So the proc was showing up as a new object (which I missed), and also showing up as a drop. This also means if the "delete" option is not ticked, it'll try to create an already existing proc and the script will fail. So looks like there needs to be some more handling around renaming procs with case sensitivity turned on. So the 2 bug fixes are: 1) Snapshot -> DB is ignoring case sensitive renames of procs (and others?) 2) Case sensitive renames of procs (and others?) need to be shown as a modification in the interface, but scripted as a separate drop/create in the script. / comments

Actually I've found the issue (for my problem at least). Half my fault, half app's fault. Issue was "case sensitive comparison" is turned on. * When comparing with snapshot it incorrectly shows dat...

0 votes

Just did final comparison: DB (Live) -> DB (Target) - missing proc DB (Snap) -> DB (Target) - no missing proc DB (Live) -> DB (Snapshot) - identical [image] / comments

Just did final comparison: DB (Live) -> DB (Target) - missing proc DB (Snap) -> DB (Target) - no missing proc DB (Live) -> DB (Snapshot) - identical

0 votes

I'm having a similar issue. I'm doing a comparison for an upcoming deployment. DEV -> FINAL And Compare 12.2 is saying that a stored procedure has been deleted from the source (dev) when it definit...

0 votes

How can we help you today?

Chris_F

Comments