SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


SQL Server Collation Choices


SQL Server Collation Choices

Author
Message
NigelFN
NigelFN
SSC Veteran
SSC Veteran (227 reputation)SSC Veteran (227 reputation)SSC Veteran (227 reputation)SSC Veteran (227 reputation)SSC Veteran (227 reputation)SSC Veteran (227 reputation)SSC Veteran (227 reputation)SSC Veteran (227 reputation)

Group: General Forum Members
Points: 227 Visits: 370
Hi there, please can I get some opinions on the subject of Server Collation.

We are in the process of configuring a new SQL Server 2005 and we wish to choose the best Collation setting - for backwards compatibility, and to ensure that we do not hit problems in the future.
We realise that the main consideration is to have consistency between various environments.

The potential choices are either “SQL_Latin1_General_CP1_CI_AS” or “Latin1_General_CI_AS”.

Microsoft documentation shows that “SQL_Latin1_General_CP1_CI_AS” is the US default, but there is also much talk about the SQL prefixed collations being superseded.

We do not make heavy use of UNICODE characters.

We are currently favouring the use of “SQL_Latin1_General_CP1_CI_AS” – we have a legacy SQL 2000 database that will be transferred to this server.
Please advise whether the choice of “SQL_Latin1_General_CP1_CI_AS” is likely to cause any un-toward problems in the future.

Many thanks,



Steve Jones
Steve Jones
SSC Guru
SSC Guru (144K reputation)SSC Guru (144K reputation)SSC Guru (144K reputation)SSC Guru (144K reputation)SSC Guru (144K reputation)SSC Guru (144K reputation)SSC Guru (144K reputation)SSC Guru (144K reputation)

Group: Administrators
Points: 144428 Visits: 19424
I'm not really a collation expert, but since 2000 (and in 2005), databases can have separate collations, so there isn't an impact with the server collation.

If you are moving data between databases, you'd have to really dig in and see if there are potential issues with the data you use.

Follow me on Twitter: @way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com
matt stockham
matt stockham
SSCrazy
SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)SSCrazy (2.6K reputation)

Group: General Forum Members
Points: 2578 Visits: 3178
It's true that databases can have their own collations, but you can run into problems if they don't match the tempdb collation - it depends on how your code is written. I won't make any recommendations because I'm definitely not an expert in this area and it's been too long since I had to look into it in detail, but this might be one of those cases where running multiple instances of SQL is beneficial .... one instance for legacy apps, and one for whichever collation you choose to use going forward.
Sinisa-425520
Sinisa-425520
SSC Journeyman
SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)

Group: General Forum Members
Points: 75 Visits: 43
You should be aware that SQL Collations are going to be depreciated.
Another thing is use of TERTIARY_WEIGHTS function that could kill performance of any server if you use SQL collations.
In other terms - use of SQL collation and ANSI defined columns (char,varchar) in some cases(queries) yields use of TERTIARY_WEIGHTS function and table scans no matter if you have index on column or not. If you have big tables it could be a very big problem.

So, if you can, go with clean install with windows collation. Also, change database collation and column level collations to the same - windows collation.

A good starting point to go deeply is http://blogs.msdn.com/michkap/default.aspx

rgds
Sinisa
huskerwendy
huskerwendy
UDP Broadcaster
UDP Broadcaster (1.4K reputation)UDP Broadcaster (1.4K reputation)UDP Broadcaster (1.4K reputation)UDP Broadcaster (1.4K reputation)UDP Broadcaster (1.4K reputation)UDP Broadcaster (1.4K reputation)UDP Broadcaster (1.4K reputation)UDP Broadcaster (1.4K reputation)

Group: General Forum Members
Points: 1435 Visits: 409
When we set up our SQL Server 2005 server, we did some research on the collation settings and we decided on using the Windows collation (Latin1_General_CI_AI) because of the sort issues using Unicode data and non-Unicode data and also because MS is going to deprecate the SQL Collations. http://support.microsoft.com/kb/322112

However, when we migrated some of our SQL Server 2000 databases to SQL Server 2005, we did experience some issues because of the different collation settings between the TempDB and the migrated databases. We wrote a script to go through and alter the database, tables, and columns to change the collation settings of them to the Windows collation and everything works fine.


Wendy Schuman
Mohammad Mazharuddin Ehsan
Mohammad Mazharuddin Ehsan
Ten Centuries
Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)Ten Centuries (1.2K reputation)

Group: General Forum Members
Points: 1215 Visits: 2445
We are supporting SQL Server installations which has databases with non English data.
Our practice is to keep the server and database collation as SQL_Latin1_General_CP1_CI_AS
On the object level we use nvarchar for non English language string data and the respective collation.
This serves the purpose well.

Regards,
Maz

-----------------------------------------------------------
Time Is Money
Calculating the Number of Business Hours Passed since a Point of Time
Calculating the Number of Business Hours Passed Between Two Points of Time

Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search