I’m just a beginner and cannot solve one problem here. We do not have russian granule right now, but in some developed tables for maintenance module, we have additional columns for descriptions in russian/cyrillic(people of different nationalities will use the module). I have not succeeded in entering cyrillic text as data to these columns in Navision, even if input language is russian all I see is strange symbols. At he same time in other MS programs everything is ok. Does anyoane have any experience with such things?

It’s because Navision is non-unicode program. You can use only one language at the same time. But you can change it in (Windows 2000, XP) Regional and Language options, Advanced tab and choose Russian. The restart of windows will be required. After restart you will be able to write and read in Russian but no Estonian characters will be available. And after changing back to Estonian, Russian characters will not be readable.

Thanks, I guess it is all I needed to know.

Additional question: We have Navision database installed on the SQL server with collation of Estonian language (code page 1257). If we try to enter in Navision at Russian language we see “garbage” instead of Russian letters. From SQL Enterprise Manager we can alter the data in tables and write them in Russian, because SQL server 2000 can change collation for every column. But when we open that table with Navision, we see only “?” signs instead of Russian text. We know that Navision is non-unicode program. If we change in Regional Option language for non-unicode program from Estonian to Russian, we cannot open the datababase from SQL server. But if the database is local (non SQL) we can open it and enter Russian letters, of cause some Estonian letters is not visible, but this is not critical. How can we enable support for Russian and Estonian languages simultaneously on SQL version of Navision?

When using a Navision Server database (native) there is no code page check of the client machine with the database contents. With the SQL version the code page check is done - to prevent inconsistencies in the data. If you are using 3.70 and are not bothered about such inconsistences you can disable the code page check in SQL, in File/Database/Alter - in the integration tab - ‘Validate Code Page’. This will for example allow you to use your Estonian database with CP1257, from your Russian client with CP1251.

New question: We are using Navision 3.60, but in this version we haven’t this tab ‘Validate Code Page’. How can we disable code page check in 3.60 version?

Maybe you should just use 3.70 clients… BTW. I worked for Russian customer running on SQL 3.60 Russian Collation, etc. I had to use Russian as Language for Non-Unicode programs (3rd tab on Regional Settings) if I wanted to connect to DB. After that I was just switching between 3 Input Languages (Slovenian,Russian,English - 2nd tab,Details) and typed whatever I wanted to in each selected language…

Form 3.70 Help: The Validate Code Page option is selected by default. When this option is selected, every time a client connects to the database the OEM or ANSI code page that is used by the client computer is checked to make sure that it is compatible with the code page used by the database. When this option is not selected, the code page that is used by the client computers is not validated. You can disable this option if you are sure that every character is converted correctly between all the clients and the database. Disabling this setting allows clients that are using different regional settings (code pages) to use the same database even though special characters entered by one client may not be interpreted correctly by another client or by the server. Other problems that can be caused by not validating the code page are: The sorting of textual data is governed by the database server and this means that the data may not be sorted according to the rules specified on the “incompatible” client computers. This problem will be more acute if there is some C/AL code that only works correctly when a particular sort order is selected. If you are accessing SQL Server with external tools, these tools may not be able to read the data that has been entered by the “incompatible” clients correctly.

Does this look familiar ?