Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 809
  • Last Modified:

SQL Server Collation for central european characters and other languages

I need to store central european characters eg Slovenian in my SQL Server 2000 database as well as English and western european characters. Am I right in thinking that using the default SQL_Latin1_General_CP1_CI_AS collation won't do the trick ? which collations do support central european characters ? I think SQL_Latin1_General_CP1250_CI_AS does support central european but are there any other options ?

what I don't really understand is how to choose which collation to use because what I really want to be able to do is store characters from any language in my database. if I wanted to store translations from every language in my database is there one collation that can do that ? eg I'll probably need to store chinese as well at some stage. do I need to have a number of different databases with different collations to support all languages? if so, what different collations would I need for that ?
0
TomWilmott
Asked:
TomWilmott
  • 2
1 Solution
 
muzzy2003Commented:
Well, you need unicode data types (nvarchar not varchar, nchar not char, ntext not text). The collation doesn't determine what characters are available, only how they are compared and sorted.
0
 
TomWilmottAuthor Commented:
I'm using nvarchar but when I insert a slovenian string into a table in a database that uses SQL_Latin1_General_CP1_CI_AS and then select the row from the table using query analyser, the string isn't displayed the same as the original that was inserted. some of the special characters are missing.

 but if I do the same thing in a database using SQL_Latin1_General_CP1250_CI_AS the select returns exactly the same as was inserted.

that's ok, but slovenian is just one of many languages I'll need to support.
0
 
slamhoundCommented:
Just make sure that every required font set is installed on your server/computer. If you are using nvar, ntext etc, the database will be storeing whatever you feed it. If you don't have the font (code page) installed, the DB will return the correct result but not display it correctly.

You will also need the correct code pages installed on the the computers that are receiving the output from the SQL server. The server may spit out Chinese characters but unless the recipeint has the properly installed font, they will just see garbage.

You can find the code page/unicode/fonts stuff in Regional Settings.
0
 
TomWilmottAuthor Commented:
thanks both. the problem was that the data being inserted into the db didn't have an N in front of the string. that works ok if the collation is CP1250 but not if collation is CP1.
0

Featured Post

Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now