We are running Navision over citrix on a W2K server ( english ). We are publishing Navision Attain via a seamless application. It works fine for english users, but when using a czech granule for our czech company, some chars with accents turn into questions marks, for example, the word " èástka " , c with the accent on top changes to a " ? " when cut and pasted into Navision. Its almost as if Navision cant cope with all the character mappings native to windows? Does this make any sense? Any help would be greatly appreciated Zaph
I forgot to mention I have added central european language support, via the regional options icon within control panel. 
Try to change the code page(set as default one in the region) of the terminal server to the language you are working at (Czech). Richard
Error message I get when the locale code page has been set to czech as default in regional options:- __________ The current ANSI or OEM code page on your computer does not match the 1252 code page of the SQL_Latin1_General_CPI_CI_AS collation for the Attain Development database You must ensure that either the ANSI or OEM code page matches the database code page. ___________ So does that mean I need to change some settings in SQL, and if so where? Will that enable both UK and Czech ppl to work off the same database Thanks in advance
Attain only allows you to connect computers with collation settings (ie. locale settings) that are “compatible” with the collation setting of the SQL Server database. UK and Czech locales are not compatible with any one database collation. So you cannot connect both UK and Czech locale computers. Regarding your original problem: As the database uses single byte character representation, you must select a character set (part of the collation setting) for the database. As no one character set contains all the characters needed for, say, both Central European and Western European, you have to limit yourself to a subset of the characters. Too bad! The manuals contain quite some material about these issues. - Jens
Jens, As far as i understand it this Attain Limit is in the stx file only, here in Aisa this limit is removed. Here for example customers are running clients with Chinese,Japanese,Thai,Korean or of course also Western European codepage configured in their System locale on a SQL Server database with the collation as per normal default SQL_Latin1_General_CPI_CI_AS This means that they can store any language data in the SQL server since the SQL Server do not really do more than store the Bytes. When it comes to viewing the data it is decided by the Locale codepage.
Hi Johan and Zalph, The problem, I belive is, not with storing the data, but with displaying it. I have preety much the same issues with Arabic. Althogh codepages have been changed, and Arabic is displayed in the Navision Bar, in the fields it comes out only as junk. For Example: The Item Card dsiplays the Description in the Item Card Blue Bar. When you type in Arabic, it displays perfectly in the Blue Bar, but in the field itself it is junk. No solution to this issue, sorry. Even teh reports will not print or display the fileds crrectly. You have to save the report in HTML format in order to view the different language. regards Omair
Maybe we are down to the same old problem that Navision uses ASCII and ANSI? I sometimes have the same problem with the Danish letters Ø (oe) on several PC’s, and only setting the base/default codepage for the PC fixes that.
Yes, correct the whole promlem would be none existing if Navision was UNICODE based…and therefore looked at the User Locale instead of the System locale… And that would also make the application possible to deploy in 1 Terminal Server over countries that are using diferent codepages for their locale languages…