• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1297
  • Last Modified:

Collation problem in SQL Database

Our Web Product is running only for English language but now we need to run it for other language as well. Right now we want to run our product for Russian language but our database collation is "SQL_Latin1_General_CP1_CI_AS" but collation is different of client sql server. Now let me know best solution to solve it. Tell me which is the best solution for me to run my application to all languages either i need to change database collation or go for other solution
0
imrancs
Asked:
imrancs
  • 5
  • 2
  • 2
1 Solution
 
Mark WillsTopic AdvisorCommented:
Need to make sure all your datatypes ar unicode - e.g. instead of varchar, use Nvarchar... There is some good documentation in Books On Line - see : "International Considerations"
0
 
adatheladCommented:
If the collation is different, your options are:

1) Change the collation of one of the databases to match the other. This isn't quite as simple as it sounds, as you can specify the collation at COLUMN level. So changing the collation of an existing database will only take effect for NEW objects created from then on - all existing objects will still use the original collation. So you'd really have to change the collation of the database AND all the varchar/nvarchar etc columns in the database.

2) Change your queries to include the COLLATE statement
e.g.

SELECT *
FROM DatabaseA.dbo.SomeTableA a
    JOIN DatabaseB.dbo.SomeTableB b ON a.SomeKey = b.strKey COLLATE SQL_Latin1_General_CP1_CI_AS
0
 
Mark WillsTopic AdvisorCommented:
Yes, that is true for collation, but in multi-lingual user world, it is not gong to translate languages...that is quite different.

Think it is a matter of having unicode character data types and a consistant collation for the database. Collations do not really apply to unicode columns (or numerics, or dates etc), just really to single byte character columns (char, varchar)

Possibly best represented by :

select * from sys.syslanguages

@adathelad : it sound like what you are indicating, is to get the content to read the same by using collation, where as collation represents a character set or code page, not a language.

e.g.

select days from sys.syslanguages where langid = 21
select days COLLATE SQL_Latin1_General_CP1_CI_AS from sys.syslanguages where langid = 21
select days COLLATE Ukrainian_CI_AI_KS_WS from sys.syslanguages where langid = 21

still all reads like russian to me...
but then as character columns, check out what happens...

select convert(varchar,days) from sys.syslanguages where langid = 21
select convert(varchar, days COLLATE Ukrainian_CI_AI_KS_WS) from sys.syslanguages where langid = 21


So, morale of the story, is collation is a code page or character set needed for character based datatypes, not unicode, and certainly not a language translation.

Language converters are not great, and needed for a true "localisation" of data from the central database to an individual user, if and only if you can identify the language of original for that data set, and the language of the recipient client...
0
Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

 
adatheladCommented:
Although I read the original question, I think I "read" it completely differently and took the wrong meaning from it based on similar issues I've worked on before.

The scenario I was talking about was quite rightly as you say not to do with language support, but specifically for the collation. i.e. the scenario where you have a query that is failing due to collation differences between the objects it is querying and so the need to resolve that error. I (wrongly/hurriedly) assumed that was the issue....but it's now clear I completely misread the question!
0
 
Mark WillsTopic AdvisorCommented:
either that or I did :0)
0
 
imrancsAuthor Commented:
If i change my data type to unicode then i don't need to change database collation. I also using temp tables.
0
 
Mark WillsTopic AdvisorCommented:
If that s a question, then yes that is correct. There is one small implication, that collation can determine sort sequences as well, so might need to look into that - but in a multi-language database, the best way to display sorted data is once you know the client language, and can use collation when extracting data for a specific language that would sort data differently - collate key word is available as part of the select statement.
0
 
imrancsAuthor Commented:
I can not use collation in my select queries and with creating temp table because i have very huge database then what do you think? i need to change my datatype into UniCode and also need to match my database collation with client machine as well.
0
 
Mark WillsTopic AdvisorCommented:
definitely unicode... no question about that.

The thing about unicode and collation is in using collation more for sort sequences than the characters themselves.

e.g.

declare @tbl table (nc nvarchar(100))

insert @tbl
select 'choir' union
select 'chess' union
select 'coin' union
select 'cat' union
select 'clown'

select nc from @tbl order by nc COLLATE Cyrillic_General_CI_AS
select nc from @tbl order by nc COLLATE Traditional_Spanish_CI_AS


So, if you truly have an internation requirement, then there are somethings you do need to know about your end user. It does get even more interesting with languages in terms of date format, number formats etc...

But, for your question, Unicode is the answer.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

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