is there any query that changes collation language not only database but also mssql server So that databases will be created in new collation language? Or do I have to establish database again?
Even if the link above is correct, I think it need some comments.
In order to change SERVER COLLATION you should rebuild system databases, and this means that after rebuild your instance will have only empty system databases.
All the information about databases previously attached to the instance will be lost. Of course you can first detach all the user databases and than re-attach them, or restore all the user databases from backups, but all your logins and linked servers will be lost.
You'll also find your msdb empty, so all your jobs, backup/restore history will be lost.
At this point may be you find it easier to re-install SQL Server with the correct collation since the result will be pretty the same: an instance with the correct collation and only empty system databases attached to it.
P.S. If you have already some databases with collation A and you change the server collation to collation B, after databases restore/re-attach they will preserve collation A. And some code using temporary tables may be break after this, it will fail with the errors "Could not resolve collation conflict"
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.
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.
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
I have a two big programs that connect to a SQL Server 2005 database.
Now we will migrate to a new server with SQL Server 2008.. the programs don't work anymore when connected to the new server, the cause is that in all the queries in the programs only table names are used, and they are not dbo tables.. so SQL Server 2008 doesn't recognise them, unless I use the schema name before the table name...
It is very very difficult for me to change all the queries in the two programs to add the schema name before the tables names.
I read in this forum that if I specify the default schema the problem will be solved.. but it haven't been solved though.
The only solution that seems to be working is when I changed the schema of the table to dbo.. but I am not sure if this action will be OK or will it cause some other problems related to this modification?
Is there any better solution?
Will changing the schema of the tables cause me other kind of problems?
Many thanks in advance
Default schemea will work for you. What are the issue with this approach?
Change schema name will cause a big issue and not advisable. Where and how much schema name change?(just think).
You just set a default schema with only one procedure first and check, if this is ok. then change the whole database schema.
https://dba.stackexchange.com/questions/21158/net-sql-server-authentication-schema-issue
In sql server 2005, how do I change the "schema" of a table without losing any data?
Change Schema Name Of Table In SQL
Best practice for SQL Server 2008 schema change
is there any way to change the master database collation in MsSql server 2008 to another collation, instead of reinstall it ?
You need to rebuild/recreate the master database as described here.
(Though that article also goes through the steps to change all user databases to the new collation you probably just need to follow the steps here)