Skip to content
← SQL Source Control

How can we improve SQL Source Control?

SQL Source Control

Categories

JUMP TO ANOTHER FORUM

(thinking…)

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 1.1.3.4 connected to a Fortress 2.0.x repository.

120 votes
Vote

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
You have left! (?) (thinking…)
Mark Caldwell shared this idea  ·   ·  Report…  ·  Admin →

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • Kevin Pohlmeier commented  ·   ·  Report

    What is the name of the option in ComparisonOptions.xml? I have version 3.5.6.338, 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.

  • Anonymous commented  ·   ·  Report

    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  ·   ·  Report

    How do you change the off/on case-sensitive comparisons option in the ComparisonOptions.xml. I cant find a matching option for that.

  • Micky commented  ·   ·  Report

    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 (Project Manager - SQL Lighthouse, Redgate) commented  ·   ·  Report

    SQL Source Control v3.0.5.7 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.

  • TechTank commented  ·   ·  Report

    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.

  • Database Evangelist. Ph.D, DPHil, MCS, BSC, MBCS, MCPD, MCDBA commented  ·   ·  Report

    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  ·   ·  Report

    This has been causing me no end of issues

  • Harley commented  ·   ·  Report

    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?

  • Michael commented  ·   ·  Report

    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  ·   ·  Report

    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 (Product Manager, Redgate) commented  ·   ·  Report

    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.