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.
Related
I can't seem to find a way to set the default collation of a database to utf(ish). For example:
For example, in mysql the default utf collation is called utf8_general_ci. Is there something similar for SQL server for this? Also, what does it use Latin1 as default?
According to https://learn.microsoft.com/en-us/sql/relational-databases/collations/collation-and-unicode-support?view=sql-server-ver15#utf8, you add "_UTF8" to the collation name to enable use of UTF8. (SQL Server 2019 is required.) The example given is to change LATIN1_GENERAL_100_CI_AS_SC to LATIN1_GENERAL_100_CI_AS_SC_UTF8.
If you will be migrating an existing database from a older version, I believe extra care is required to insure collation conversion is handled properly. There can be side effects from the change in sorting. Also, existing table definitions will use their original collation. This might be an issue if creating new tables that will use the new collation by default.
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 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.
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"