March 16, 2010 at 11:12 am
Sql 2005 standard sp3
We are planning ‘internationalization’ project; meaning that our applications and databases are supposed to
accept international characters such as Chinese, French, Spanish, Cyrillic etc.
Any ideas, pointers or suggestions on what needs to be done sql server configuration wise?
Never had to deal with it before.
March 16, 2010 at 11:38 am
I'm sure there are more but be sure to define any character fields that will give display text to the front-end are defined as nchar or nvarchar and not char or varchar.
You may also want to look at Server and Database Collation. I'm partial to the Case INsensitive ones myself..
CEWII
March 16, 2010 at 2:02 pm
SD1999 (3/16/2010)
Sql 2005 standard sp3We are planning ‘internationalization’ project; meaning that our applications and databases are supposed to
accept international characters such as Chinese, French, Spanish, Cyrillic etc.
Any ideas, pointers or suggestions on what needs to be done sql server configuration wise?
Never had to deal with it before.
Cyrillic and Chinese require more than Nchar and Nvarchar you must use correct collation, there are at least five Chinese defined in both SQL Server and .NET so you need to find the correct version of Chinese you need because the Chinese alphabet is more than 2500 character compared to the 26 character Latin alphabet. In .NET use System.Text.Encoding and use the SQL Server collation you need for each language, if you choose to accept Chinese and English in one column it can get complicated.
Kind regards,
Gift Peddie
March 16, 2010 at 2:18 pm
Thank you ALL for the info!!!
However I do have a question. Why does it meter how many characters is in the alphabet?
As long as the nvarchar or nchar is set….
March 16, 2010 at 2:22 pm
I am definitely going to defer to Gift Peddie on this, I have not dealt specifically with Chinese or Cyrillic alphabets. But it sounds good to me..
CEWII
March 16, 2010 at 2:43 pm
Another subject you need to focus on is how you handle date formates both within your tables (e.g. stored as character... :pinch:), and within all queries/stored procedures.
If you provide any date information from the frontend to a sproc, make sure you use a standardized format (e.g. yyyymmdd).
Also, check for any kind of usage of the DATEPART and DATENAME function, especially in terms of dw (day of week) or wk (week). If you find it, make sure you'll get consistent result for any language that is ued.
I strongly recommend against using SET DATEFIRST or SET LANGUAGE anywhere in your underlying code to overcome some issues you might have with data structure or coding itself. Fixe the table structure and/or the code instead. Otherwise you'd need to make sure to change it back to the previous setting whenever the batch/trasaction is done, even and especially in case of possible errors. It's likely to become a nightmare...
March 16, 2010 at 2:44 pm
SD1999 (3/16/2010)
Thank you ALL for the info!!!However I do have a question. Why does it meter how many characters is in the alphabet?
As long as the nvarchar or nchar is set….
Check below Microsoft have finally covered what I have been explaining for years because the SQL Server 2008 NChar/NVarchar is the same as the .NET Char.
http://msdn.microsoft.com/en-us/library/ms143503.aspx
Kind regards,
Gift Peddie
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply