Well we have a so-called APAC (asia pacific) database which should cover all our APAC companies. These run in countries such as Japan, China, Hong Kong, Singapore and Australia. Today only our Japanese company runs it it. And this is due to the fact that the collation is set to Japanese.
Which collation should be the recommended for a all Asia (using primary English, some Japanese and a little Chinese)?
Good question. Do all users work in English or do they work with local languages in script?
Most users work only in English, but some Chinese and especially Japanese is also used especially in name, address and description fields.
Can it really be true that nobody knows anything about this??
If you want to have one database for all countries for SQL2000 (one collation for all asia countries) the best collation according to ESG (now Tectura) is:
“You must use SQL Collation if you are using double-byte. For optimal performance, you should choose Western-European dictionary sort order, code page 1252, case-insensitive, accent-sensitive (52) collation.”
However I am currently running double-byte countries in one central code page 850 with no more issues than I have heard with 1252.
However for all cases if you do not select the country specific collation (for asia countries) you should NOT use double byte characters in code fields - stich to english or number characters. Code fields are in english capitalised but but in double byte using capitals is another “letter” (and this is the only issue I have faced).
We have had trouble with code page 850 and some Thai characters. Not all of them, but several. As some vowels are written obove or under the consonnants these vowels were not placed corrctly or not shown at all.
Hi Walter,
Which collation would you recommend instead for Thailand?
We have had trouble with code page 850 and some Thai characters. Not all of them, but several. As some vowels are written obove or under the consonnants these vowels were not placed corrctly or not shown at all.
Hi Walter,
Could you please elaborate on your problems having SQL2000 with collation “Scandinavian dictionary sort order, code page 850, case-sensitive, accent-sensitive (59)” as I am using this without problems for both Chinese and Korean. The only issue is that they should not use these characters in code fields. (However this collation has the problem that it does not distinguish between v and w)
Are your problems when printing or when searching in description fields or on screen ??
Hi Erik,
Our technicians recommend Codepage 874
Hi Kim,
in only some cases the “combined” char will not displayed (and printed) correctly using cp850.
e.g. you write “mi” which will be the character “i” written on top of the “m” (ม) < see here it is not working as well :-)) Only the “m” is displayed. Above the “m” should be the “i”. We are (normally) not using Thai characters in code fileds.
Searching in description fields results in the same problem (with cp850) because you cannot enter this “mi” als only the “m” is shown.
Regards
Walter
As I have understood the collocation is mainly about sorting.
We are today running 30 countries on the same database and same server with collation 850. The countries include Korea, Taiwan and Turkey (where they all need a special client to view the characters) but I have no problems with the collation on the server.
Next month we are starting implementation in Thailand and therefore I would very much prefer if you could elaborate on which problems could occur choosing another collation.
I agreed that the default OS on the client should Thai but I would prefer to be able also to run Thailand in the same database and server as all other countries.
Thanks for you assistance.
I think the messages crossed.
I will test and see if I get problems with these characters.
Hi Kim,
in only some cases the “combined” char will not displayed (and printed) correctly using cp850.
e.g. you write “mi” which will be the character “i” written on top of the “m” (ม) < see here it is not working as well :-)) Only the “m” is displayed. Above the “m” should be the “i”. We are (normally) not using Thai characters in code fileds.
Searching in description fields results in the same problem (with cp850) because you cannot enter this “mi” als only the “m” is shown.
Hi Walter,
I am not sure which kind of Thai you have selected because I dont at any time (I am trying first in word) get the “mi” where the “i” is on top. I have tried with following characters first in word and second in excel without problems.
ฟิแกำดเร่าสทืนยๆพหะไรี
The keyboard is set to “Thai Kedmanee”.
Could you please let me know how to change setting so I can write the problematic letter in word.
Thanks in advance,
Kim
Hi Kim,
will do. Unfortunatly I am in France right now and do not have my thai keyboard here. But I will ask tomorrow in the office to assist.
Kind regards
Walter
BTW: you typed the “fi” = ฟิ . So you got the “i” on top of the “f”. However, not all combinations have problems. I will let you know tomorrow.
Ok, the problem is that the vowels are NOT “shown” while typing into text and/or code fields. After validating (hit enter key) they are displayed correct. Still have that problem in the latest Navision version.
Examples:
Vowels up (top of the consonant): ห้ ห่ หี หี่ หี are shown without the vowels on top while typing
Vowels down (under the consonant): หุ หู are shown without the vowels while typing
After validating the vowels are shown. However, while you use a “searc as you type” you will not find anything until you hit the enter key.
Sorry for messing that up. But I am normally not writing in Thai. Just have to read and only write if I have to do a search for an entry.
Hi Walter,
Thanks very much for your detailed explanation.
I have just tryed with a Thai client (default OS = Thai) and a navision database on SQL2000 (however danish keyboard acting like a Thai keyboard).
I have no problems seeing the vowels as you describe while typing. Both in word but also in navision and also when I do searching. My collation on the sql2000 is “Scandinavian dictionary sort order, code page 850, case-sensitive, accent-sensitive (59)”
So I assume I am just lucky and will be able to keep also my Thai company in the same database.
But while upgrading to SQL2005 next year I was planning to change to windows collation. Do you know about any problems using double-byte characters against windows collations ?