January 31, 2012 at 6:04 am
Hi,
I'm going to change my DB to support 5 different languages. Right now the collation is 'SQL_Latin1_General_CP1_CI_AS'. I've changed datatype to NVARCHAR and inserted the different languages. It supports.
But, I want to know is there anything else I have to look upon to suppport different languages.
If you can address many languages with 'SQL_Latin1_General_CP1_CI_AS' collation then why we have difference set of collations in SQL server.
thanks
regards
ami
January 31, 2012 at 7:35 am
Anamika (1/31/2012)
Hi,I'm going to change my DB to support 5 different languages. Right now the collation is 'SQL_Latin1_General_CP1_CI_AS'. I've changed datatype to NVARCHAR and inserted the different languages. It supports.
But, I want to know is there anything else I have to look upon to suppport different languages.
If you can address many languages with 'SQL_Latin1_General_CP1_CI_AS' collation then why we have difference set of collations in SQL server.
thanks
regards
ami
Collation and unicode are two different things. The nvarchar datatype is unicode, so it can store pretty much all languages. However, sorting can still behave differently between various collations.
An example from MSDN:
For example, in an ORDER BY clause, an English speaker would expect the character string 'Chiapas' to come before 'Colima' in ascending order. However, a Spanish speaker in Mexico might expect words beginning with 'Ch' to appear at the end of a list of words starting with 'C'. Collations dictate these kinds of sorting and comparison rules. The Latin_1 General collation will sort 'Chiapas' before 'Colima' in an ORDER BY ASC clause, whereas the Traditional_Spanish collation will sort 'Chiapas' after 'Colima'.
More info on Unicode:
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
February 1, 2012 at 2:04 am
good info Verbeeck.
you are right. I'm doing a Unicode analysis.
thanks for your input.
regards,
ami
February 2, 2012 at 9:51 pm
I'm changing all the non-unicode columns to support unicode keeping in mind the space required for the same would be doubled.
Addressing all the procedures to reflect the same. as im going to use multiple languages, the sort order of the same would be defined at procedural level with varying ORDER BY clause.
I'm addressing all casting and ASCII() and CHAR() functions.
then, prefixing the constants in the stored procs with N''.
is there anything else to look out?
thanks,
regards,
ami
February 2, 2012 at 11:16 pm
If some indexes include columns that have changed datatype, you could rebuild them.
Need an answer? No, you need a question
My blog at https://sqlkover.com.
MCSE Business Intelligence - Microsoft Data Platform MVP
February 3, 2012 at 2:13 am
Good Tips.
thanks,
ami
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply