problem with russian letters in database created in CZ lang

Doomhammer

Hi
We encountered this kind of prob:
we've got customer with HQ in CZ and with branches in some european countries.
Because customer started in CZ, we created database using czech language setting of client.
now, customer expands into Russia and we have problem - when user enters russian letters into field with data type CODE, after validating, russian letters are interpreted as nonsences. the same result is done by UPPERCASE funct.

There exists following bug with russian characters encoding into database in NAV 4.0 SP2

Uppercase (and similar Lowecase) function designed for transformation lower case letters to upper case (and vice versa) and simile function, which converts text into CODE data type performs conversion of russian alphabetic characters in database created in russian language environment following way:

char Code CharID idC Uprecase
а А 160 128 А
б Б 161 129 Б
в В 162 130 В
г Г 163 131 Г
д Д 164 132 Д
е Е 165 133 Е
ё Ё 241 240 Ё
Ё Ё 240 240 Ё
ж Ж 166 134 Ж
з З 167 135 З
и И 168 136 И
й Й 169 137 Й
к К 170 138 К
л Л 171 139 Л
м М 172 140 М
н Н 173 141 Н
о О 174 142 О
п П 175 143 П
р Р 224 144 Р
с С 225 145 С
т Т 226 146 Т
у У 227 147 У
ф Ф 228 148 Ф
х Х 229 149 Х
ц Ц 230 150 Ц
ч Ч 231 151 Ч
ш Ш 232 152 Ш
щ Щ 233 153 Щ
ъ Ъ 234 154 Ъ
ы Ы 235 155 Ы
ь Ь 236 156 Ь
э Э 237 157 Э
ю Ю 238 158 Ю
я Я 239 159 Я


Character conversion is performed this way:

Char Code CharID idC UpZnak
а ‚ 160 181 ‚
б © 161 214 ©
в р 162 224 р
г щ 163 233 щ
д д 164 164 д
е д 165 164 д
ж ж 166 166 ж
з ж 167 166 ж
и и 168 168 и
й и 169 168 и
к к 170 170 к
л Н 171 141 Н
м м 172 172 м
н … 173 184 …
о о 174 174 о
п п 175 175 п
р р 224 224 р
с с 225 225 с
т т 226 226 т
у у 227 227 у
ф у 228 227 у
х Ґ 229 213 Ґ
ц ц 230 230 ц
ч ц 231 230 ц
ш ш 232 232 ш
щ щ 233 233 щ
ъ ш 234 232 ш
ы ы 235 235 ы
ь э 236 237 э
э э 237 237 э
ю ґ 238 221 ґ
я я 239 239 я
Ё Ё 240 240 Ё
ё ё 241 241 ё


Many actions in russian language option are not working correctly.

Rule for Uppercse conversion are created in time of database creation process and they are based on language (STX) selected in time of creation.

Czech chars with diacritical signs are interpreted incorrectly too, then database was created in russian environment and after creation, language was set to czech

Czech correct

Char Code CharID id code Upercase
á Á 160 181 Á
č Č 159 172 Č
é É 130 144 É
ě Ě 216 183 Ě
í Í 161 214 Í
ř Ř 253 252 Ř
š Š 231 230 Š
ý Ý 236 237 Ý
ž Ž 167 166 Ž

Russian incorrect

char Code char id code uppercase
á Ç 160 128 Ç
í ü 161 129 ü
ó é 162 130 é
ú â 163 131 â
Ą ä 164 132 ä
ą ů 165 133 ů
˝ ¬ 241 240 ¬
Ž ć 166 134 ć
ž ç 167 135 ç
Ę ł 168 136 ł
ę ë 169 137 ë
¬ Ő 170 138 Ő
ź ő 171 139 ő
Č î 172 140 î
ş Ź 173 141 Ź
« Ä 174 142 Ä
» Ć 175 143 Ć
Ó É 224 144 É
ß Ĺ 225 145 Ĺ
Ô ĺ 226 146 ĺ
Ń ô 227 147 ô
ń ö 228 148 ö
ň Ľ 229 149 Ľ
Š ľ 230 150 ľ
š Ś 231 151 Ś
Ŕ ś 232 152 ś
Ú Ö 233 153 Ö
ŕ Ü 234 154 Ü
Ű Ť 235 155 Ť
ý ť 236 156 ť
Ý Ł 237 157 Ł
ţ × 238 158 ×
´ č 239 159 č

- Is there any posibility to change Uppercase function behavior after DB was created?
- Is there posibility, how to change uppercase’s behavior programmaticaly?


With our licence and database access, we did not discover no way how to change uppercase functionality
We found following solutions :
1) In russian company can be used only numeric values in code type fields. Nonsenses in search description must be ignored
2) Perform backup of customer’s production DB, creation of new one in RUS language selectiion and restoring all data – no CZ diacritics can be used in code fields.
Those are worst-case scenarios, we would like to know better solutions, if there are any possible.

Thanks for ideas

kine

As you already know, the problem is combination of more things -
1) Settings in STX file (string beginning with ID 00043-00100-200-1 and other) - these strings define the pair lowercase/uppercase for each character.

2) Windows language settings for non-unicode application on client - this have impact to how the characters are displayed and recoded when entered through keyboard.

3) Windows language settings for non-unicode application on server - in case of Native DB server, it saves the data in given codepage.

4) If you are using SQL server, there is the Collation which have impact to how the data are saved.

As you can see, it is very complicated to make all these settings correctly and it is not possible to do that in case of using more codepages on clients, because NAV is not unicode. IN this case is good to use only some ASCII characters which are correct in both codepages, if you are using one DB. Or you can use two databases etc. but it depends on more things around that...