Capitalization Change as Name Change
In a case-INsensitive collation, I changed the name of a stored procedure to fix a capitalization issue. This was first detected as a change (displayed the blue dot on the procedure and hierarchy in Object Explorer) but then when I went to the Commit Changes window and clicked the Refresh button, nothing appeared, and the blue dots disappeared.
Even though my data collation is not case sensitive, I would have expected this to be recognized as a name change.
Using version 188.8.131.52 connected to a Fortress 2.0.x repository.
My Column changed it's case from Columnname -> ColumnName was not detected, this should be detected on commit changes
Kevin Pohlmeier commented
What is the name of the option in ComparisonOptions.xml? I have version 184.108.40.2068, and I don't see anything about "case" in that file.
The link from Chris Smith about how to set "this option" is really just a link on how to set options in general.
this issue also happens when changing the case for text strings inside code, for example 'test' to 'TEST'. for us is an issue when we use case sensitive XML Path declaration. It has costed us hours of troubleshooting for not commiting the changes. The object changed regardless of the collation, this need to be fixed.
Mårten Holm commented
How do you change the off/on case-sensitive comparisons option in the ComparisonOptions.xml. I cant find a matching option for that.
Object names should be case sensitive by default. The same options that are available to SQL Compare should be available to SQL Source Control.
AdminChris Smith (Admin, Red Gate) commented
SQL Source Control v220.127.116.11 includes a mechanism to allow comparison options to be configured - including the ability to turn off/on case-sensitive comparisons. To get this version, please run Check For Updates from the Help menu in SQL Source Control.
Comparison options can now be set via a configuration file in your database repository's Working Base folder. We'd be interested to hear if this meets the requirements for this 'Idea'.
The following article describes how to configure this option: http://www.red-gate.com/SupportCenter/GeneralContent/knowledgebase/SQL_Source_Control/KB201202000521
Our plan in the future is to provide an options dialog to allow users to configure the comparison options that are changed most often, but we believe this configuration file procedure should help users in the interim.
If you'd like to see an options dialog exposing these settings in SQL Source Control, please vote on the following idea - https://redgate.uservoice.com/admin/forums/39019-sql-source-control/suggestions/2615460-add-an-options-dialog-to-allow-configuration-of-co - and let us know which options you'd like to see exposed in the dialog.
I believe this needs some more attention as the points I wanted to raised have already been raised below so just some extra *bumpage* and please look into this issue.
This happened to me before. It should recognize it as a name change. The fact that it doesn't is imho a serious design flaw that needs patching. It could lead to all kinds of problematic scenarios. For example, if I change the name of an object, and I am using case-INsensitive collation, and I commit it, it won't recognize the name change and then I'm totally in trouble....
Deadlines could be missed! Problems will be passed onto App Support. DBA's will be stressing.
Please fix this.
Paul Gray commented
This has been causing me no end of issues
Franz Junge commented
Schoolboy error IMHO!
I agree with the comments below. I should be able to put under source control any changes I make in case to any objects, regardless of the collation. Can this be fixed, as I cannot check in changes to TFS using source control?
In a stored proc comparison, "CREATE" and "create" were flagged as different. That doesn't seem necessary. I assume that many of the schema comparison features of SQL Compare will eventually find there way into this product. I think they will be needed.
Troy Hunt commented
I believe case sensitivity and collation are two entirely different issues. From my perspective, I should be able to put under source control any changes I make in case to any objects, regardless of the collation.
Case in point; if I make a case change to a column in a case INSENSITIVE collation then use LINQ to SQL to persist the DB objects, the case is then SENSITIVE in the .NET layer. If I can't version the DB change, things are going to break for other developers.
I've previously written about a workaround: http://www.troyhunt.com/2010/12/defeating-red-gates-sql-source-control.html
AdminDavid Atkinson (Admin, Red Gate) commented
This has come up before. Maybe we should always flag case sensitivity issues for the purposes of source controlling (and ignore the collation). I'd be interested to get other comments on this subject.