My ASP.NET application is developed with a SQL Server database with a case insensitive collation. The inline SQL scripts sometimes use variables and CTEs. In a case insensitive server, the app works perfectly fine, even if sometimes the variable names mismatch capitalization.
Recently the database team migrated our database to a different server that IS case sensitive, and some of the code path started failing.
The database team can not change the server collation because an existing database requires that particular collation. Is there a way for me to set a flag or something at connection property, or anywhere, to treat the script as case insensitive? There are more than 50 data access calls, so it would be tiresome for me to check each SQL block to ensure capitalization.
Any help?
You can set your database to be a Partially Contained Database, which will allow you to use Contained Database Collations, which completely isolate you from the instance collation, and even allow you to use a case-sensitive collation for your data, without having a case-sensitive collation for your catalog, or code.
Related
So for tests I am creating temporary docker SQL Server.
Unfortunately my production database uses some non standard collation.
So for tests I am creating test database with my custom collation. In next step using flyway I am migrating schema, but it seems like even database has my custom collation, flyway SQL statements inherit collation from SQL Server instance and I am getting collation collision exception.
Is there any way to force that every statement in database x should use database collation by default?
One important thing is that many of those SQLs are already on production, so I cannot add to them collation statement explicit.
I am in the process of installing a database onto a client's server. The collation that is set on the server is SQL_Latin1_General_CP1_CS_AS, so it is case-sensitive.
The database that I am installing uses collation level SQL_Latin1_General_CP1_CI_AS, so it is case-insensitive.
The issue I am running into now is that all variables in stored procedures must be case sensitive or else it will throw an error.
Example:
Declare #Dimension varchar(45)
Set #dimension = 'Test'
Error:
Must declare the scalar variable "#dimension".
The lowercase "d" in the #dimension variable is causing it to be recognized as a completely different variable.
Is there a setting in the database that I can update to ignore the Server's collation?
Note: I received permission to update the collation at the server level as it is a test server. However, it is a more involved process. I am looking for a way to get around this without having to go through the steps found in this link:
Make sure you have all the information or scripts needed to re-create your user databases and all the objects in them.
Export all your data using a tool such as the bcp Utility. For more information, see Bulk Import and Export of Data (SQL Server).
Drop all the user databases.
Rebuild the master database specifying the new collation in the SQLCOLLATION property of the setup command. For example:
Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=InstanceName
/SQLSYSADMINACCOUNTS=accounts /[ SAPWD= StrongPassword ]
/SQLCOLLATION=CollationName
Create all the databases and all the objects in them.
Import all your data.
Thank you
To work around this, set your database as Partially Contained. This will give you Contained Database Collation, which provides:
Since a design objective of contained databases is to make them
self-contained, the dependence on the instance and tempdb collations
must be severed. To do this, contained databases introduce the concept
of the catalog collation. The catalog collation is used for system
metadata and transient objects.
In a contained database, the catalog collation
Latin1_General_100_CI_AS_WS_KS_SC. This collation is the same for all
contained databases on all instances of SQL Server and cannot be
changed.
As per experience would be a faster way is to backup all databases then re-install the sql-server with the correct collation, then restore all databases. Might be a manual thing for permissions but there can be other options.
According to the SonarQube documentation "Installing the Server" (https://docs.sonarqube.org/display/sonar/installing+the+server), for a Microsoft SQL Server host, "collation MUST be case-sensitive (CS) and accent-sensitive (AS)."
The documentation is not clear if the collation must be set:
for the SQL Server instance, or
the database
If the collation for the SQL Server (and specifically for tempdb) is "accent insensitive" and the database collation is "accent sensitive", does SonarQube accommodate this configuration?
If the collation for the SQL Server (and specifically for tempdb) is "accent insensitive" and the database collation is "accent sensitive", does SonarQube accommodate this configuration?
Since the documentation is ambiguous (they might not use SQL Server enough to know the different levels where Collation can be set), the only two ways to get the answer here are:
Contact their community: https://www.sonarqube.org/community/feedback/. This is the best choice.
Install it on an Instance that has an accent insensitive default Collation and test it out. No reason not to try this.
Whether or not SonarQube handles this properly depends on how it was coded. They could be JOINing on string columns in temporary tables and any difference in Collation between the Database and Instance could potentially cause an error, but only if they are not specifically declaring the Collation when creating the temp tables.
Also, it is possible that their app needs the accent sensitivity because they have some variables names and/or cursor names and/or (less likely) GOTO label names that might equate under accent insensitivity that should otherwise be seen as different. Instance-level Collation controls these areas and would hence affect the name resolution of those items. Of course, this would be easy to test for since declaring two variables that are considered different names under accent sensitivity will cause a parse error if close enough to be considered the same under accent insensitivity. Still, contact their community.
Is it possible to have a SQL Server 2012 database with a collation that ensures only the data is treated as case sensitive, with the database objects still referenced in a case insensitive manner?
We are migrating the database used by an application to SQL Server, and this database contains case sensitive data. But we don't want the database objects to be treated in a case sensitive manner, as that will have a significant negative impact on the existing code.
All research tends to suggest that this isn't possible, and the best we can do is identify which columns really do need to be case sensitive, and set the collation for these accordingly so we can minimize the damage. Is this the best we can hope for?
#Cleggy, it looks like you already got the answer from #Xedni's comment, but adding it here as a reference for anyone reading this page in future.
SQL Server collation settings depend on the type of installation. Case sensitivity is subject to collation of the data.
By default, databases created with SQL Server inherit the server collation.
By default, column in tables created in a database inherit the database collation.
There are plenty of opportunities to choose a case sensitive collation for your data between these options:
By choosing one when you create the database (Or)
By choosing one when you design the table
Please follow this link for more on SQL Server Collations.
We can change the database collation to case sensitive using the following T-SQL.
ALTER DATABASE <Database_Name> COLLATE Latin1_General_CS_AS
The following T-SQL will be helpful in understanding the various case sensitivity options.
SELECT * FROM fn_helpcollations()
In SQL Server (2000 or 2005) is it possible to set the database or server collation so that identifier names (tables, columns, etc) need to be in the correct case? If so, is that true of all case-sensitive collations or is it a separate setting? (I've always thought of case-sensitivity applying to data, not to names of objects).
Presumably this would break an application if its stored procs and queries weren't written with consistent case? Is there a way to deal with this without having to ensure all queries use the correct case, such as setting the collation of a database connection?
I'm looking at this from the point of view of having an existing application which probably has inconsistently cased sql code in it, and I'm wanting to be able to run it against databases with different collations. What settings would I need or what set of database/server collations could I not use the application with?
The collation is what determines if your queries will be case insensitive. So the only way to ensure that your schema will work against multiple environments is to have your queries be case sensitive. If your queries are not consistent, then your collation MUST be case insensitive otherwise it will not work.
http://msdn.microsoft.com/en-us/library/aa174903(SQL.80).aspx
One thing to note is that once you've set up your SQL Server environment with a certain collation, you CANNOT change it without creating a NEW SQL Server instance. So Case-Insensitive is usually the way to go. And then strive to have consistency in your queries.
Once a collation is set it applies to both data and metadata, I believe.
Collation is set in earlier versions of SQL Server, but in 2005 and beyond, you can change it by object, as they are created.
The database default collation determines whether objects within the database are treated in a case-sensitive way in queries - this applies to all object name: tables, columns, etc.
If your application code comes from a case-insensitive collation database, it may not run on a case-sensitive collation database if a object is misreferenced (you would get a message when you attempted to run the statement or create the stored procedure, or in a stored-proc architecture, you would catch all these pretty quickly unless you had a significant amount of dynamic SQL).
Remember, that even if your code runs, individual columns can be set with collations which differ from the database, so it's always possible that with a differing collation, your code will behave unexpectedly (for instance, GROUP BY behaves differently).
You can set collation for each object, and set a default for the database and server as well.
How to deal with it? You need to enforce standards here. You can easily get yourself tangled up with different people write with different case.
The collation also applies to data so "bob" != "Bob"