Activity overview
Latest activity by 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 ...
Feature request: Sort objects in deployment script
When generating the sql compare deployment script - all objects are scripted in a seemingly random order.This could be covered by an option to enable/disable it.And obviously, there is a dependency...
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.
Aliases starting with S F W won't work and default to text expansion
Warning
No formatter is installed for the format not-found
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.
Aliases starting with S F W won't work and default to text expansion
When trying to write a query with single letter aliases, the keyboard behaviour is different for the letters S, F & W.Example:SELECT *Where | is the cursor.If you press the enter key you will get a...
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...
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...
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...
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...