When a database is created from our application, it takes the default Collation. we don't want to pass the collation in the create database script.
A client has a collation set on the instance level that is Case Sensitive. So the database created for our application is in that collation which is something we don't want.
Can they change the collation on the instance level so the database that gets created will have the desired collation and they can change it back to whatever they want? How do we do this on the instance level?
Thanks for your time!
So the problem is that the database is not created by a script run in, say, SQL Management Studio, but a script launched from within the application.
As noted in the comments and another answers changing the server collation is possible but hairy, the best option in a case like this is creating the database empty, changing the collation (either with ALTER DATABASE or from Management Studio), and then create the rest of the database.
This would require changing the application, but only the creation of the database itself since the tables will take the collation of the database, not the server collation (and you can do it in a way that works for every client, check if the database exists and that case skip DB creation and proceed with the rest of objects).
As a final warning, note that having a DB with a collation different of the server collation would mean than the DB has a different collation than the tempdb, so if you use temporal tables you would have problems if you have WHERE's or JOIN's mixing temporal and regular tables. For example, supposing that SerialNumber is a char column, this query will fail with a collation error:
SELECT *
FROM Products
JOIN #TempTable ON #TempTable.SerialNumber=Products.SerialNumber
If that case you will have to modify the application and change the queries to something like this:
SELECT *
FROM Products
JOIN #TempTable ON #TempTable.SerialNumber=Products.SerialNumber COLLATE database_default
You can configure the instance collation which would require dropping the databases before changing it. Here is a link to setting or changing the Server Collation.
You can also do this on a database level. Here is information on setting or changing collation on the database level.
You may also want to read the collation clause which can also be applied to tables, columns, and casting expressions among additional options.
Related
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.
Dear all, Currently I am just researching how I could handle the change of the collation on the database.
Somebody made an unusual decision to create accent sensitive database for global use... but I am on the way to handle this!
REASON: of changing the collation is that database contains data collected from different countries and as we all know some of cultures have their own letters.
With the respect for the customers, our organization would like to have Accent Insensitive database. That will allow users to request data from the server without any limitations using local characters.
As far as I have find out, there may be an option to drop constraints and etc. change collation and then just to bring everything back. In this case I am afraid if this would be enough to affect already existing data (columns).
Another way, I have found an article in Collation change on 2005 and 2008 server. However, this does not include the 2012 server.
Also I am taking the complexity of this example into consideration as well.
I believe that I am not in an easy phase. But I am hoping to get few advises what would be the best and safest way to handle this.
Thank you for your concerns and assistance.
UPDATE let me add what architecture do we have: The complete system contains 4 databases and more than 1.000 tables in total. So my expectations is that not all of the possible ways may work in an optimal way.
me too i had to deal with a similar issue because of a different reason: ancient databases with an old SQL collation installed ages ago on a SQL6.5 server that has been inplace upgraded for each version from sql 7 to sql 2005 and now should be updated to sql 2012.
why all these inplace upgrades? because the actual collation was the server collation and was so old that is not available during then install process of a recent version (2000+) of sql server...
i decided to drop all that old rubbish so i had to find a way that allowed me to move to a new installation with a windows collation.
i had to exclude the data migration (create a new database and import data) because of the lack of documentation and the huge number of customizations, triggers, hidden rules and so on.
the solution i used (the order matters):
disable automatic statistics generation
script the creation of all foreign keys and then drop them
script unique and primary indexes and then drop them
script all remaining indexes and then drop them
script custom statistics and then drop them
script CHECK and DEFAULT constraints and then drop them
now you can run the ALTER commands needed to change the collation of the columns and change the collation of the database itself.
when done repeat the above in reverse order to rebuild all the needed objects.
it happens that if the database is so old as is mine you may incur in something funny like existing foreign key that references fields with different datatypes.
Changing collation of all existing columns is a real pain. I suggest a side-by-side migration rather than alter each column individually. Create a new database with the desired collation containing only empty tables. Copy data from the old db to the new one using INSERT...SELECT (or the ETL tool of your choice), and then create constraints, indexes, and other database objects.
Consider upvoting the Make it easy to change collation on a database SQL Server feature request.
There are a number of complicated solutions on the internet for inplace collation changes but the simplest (and safest) way we have found is to script out the database, alter the script to create a new db with the collation set at the start and then import the data to the new database.
We achieve this using MS SQL Server 2012 Management Studio in the following way:
Script out all database objects with Tasks -> Generate Scripts -> Script entire Database and all Database objects
Alter the script with the following 2 changes and then run it to create a new database:
a) Change DB name to MY-NEW-DB
b) Under the CREATE DATABASE statement add: ALTER DATABASE [MY-NEW-DB] collate Latin1_General_CS_AS
If desired, use a tool like RG SQL Compare to compare the old and new database to verify all indexes, constraints, types etc were the same and collation on relevant columns only was changed.
Run Tasks->Import Data ensuring 'Enable Identity Insert' checked. All data transferred to the new case sensitive database correctly.
Run DBCC CHECKDB if you wish to check consistency
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()
I am trying to find a way of specifying a COLLATION for a user-defined data type, but it doesn't appear to support collations in SQL Server, and it basically takes the collation from the database.
Is there any way of applying a collation against a user defined data type that doesn't inherit from the database collation?
I am writing a database comparison tool, using the AdventureWorks2012 database for testing, and after generate an SQL diff script and running it on a blank database the tool is now reporting a lot of differences due to the collation being different to what was actually expected.
I could create the blank database with the same collation as the source database, but I need to consider situations where organisations, etc. may wish to change the collation on the database and my tool will not work consistently and will keep on reporting differences.
Thanks.
Transferring data from one SQL server to another but when Schema is compared and syncronised the following error is received. We are using redgate SQL compare to complete.
Cannot resolve collation conflict for equal to operation
Base SQL server is SQL_Latin1_General_CP1_CI_AS and the destination server is Latin1_General_CI_AS
SQL Compare has an option to ignore collations. Look under the tab "options" in your compare project configuration.
is you problem with the SQL Compare utlity, or a worry that different server collations will lead to problems?
You could change the collation of the destination server to match the Base server
If that is not possible, then make the Collation of the databases on each server match, and then your only real problem is likely to be any temporary tables which you create (they will have a default collation matching the server / TEMPDB), and so long as you explicitly create the temporary table (i.e. don't create it using SELECT * INTO #TEMP FROM MyTable) and explicitly assign a collation to any varchar/text columns you should be OK
The way I overcome this is to generate the scripts via SQL Compare and then strip out (or replace) the Collation specific code. This is relatively fast and easy to do, and finally I manually apply the scripts to the destination server/ database.
Sounds like the collation settings for the server are different.
How are you transferring the data, do you perform a database restore on your new platform?
Either way, you need to ensure that the same collation is used on your new environment as is currently in place in your source environment.
Hope this makes sense, let me know if you need further assistance.
"Ignore collations" is definitely not going to work, for the reason stated above. The problem happens when migrating objects like views and stored procedures that use JOIN clauses on text fields that have differing collations.
If someone changes the default collation on the server and the column on the other side of the JOIN uses a specific collation, you've caused this issue. And it would happen in SQL Compare as well as if you just manually scripted the object in SSMS and moved it yourself.
There are two roads to fixing it - you could specify a COLLATE clause on the join and explicitly state the collation you want to use, or you could change the destination database default collation to match the source.
I'm afraid there is no SQL Compare "magic bullet" to solve this.