Hi, I’m experiencing some difficulty with automatic changing characters after the import of a Navision fob file in to Navision Attain. For example: Ì becomes  without any manual changes. Ì = alt 0204  = alt 0194 Has anyone experienced the same problem, or does anyone know the solution to this problem?
I have a little codeunit to convert Ansi to Ascii and Ascii to Ansi Give me a e-mail adress to send you the fob
Fabrice, I think he also wants to know (me too) why is this happening… Anyone…
I don’t know, i have mishunderstoud the topic. I think its a problem for importing data and no a fob. I apologise
change the executebels to nav 3.70 . It’s the best Hotfix for various problems in 3.60.
Attain/Navision exports character data to files as OEM data - even if the files are binary (as is a .fob), character data originates as OEM. Which OEM code page? There are many, as with ANSI code pages. [By the way, the terms ANSII to ASCII is not meaningful because there is not 1 ANSI code page - ASCII is usually given to mean OEM code page 437]. So if you export a .fob from a computer using an OEM 850 code page, for example, and import it on a computer using 437, for example, then characters that are not equivelant in each code page will map incorrectly. These are usually the extended characters like those mentioned. Exactly the same problem occurs when accessing Navision Server from clients with differing code pages - these characters will get screwed up. Try to determine what code page was used when the .fob was exported, and ensure your other machine has the same. Note that it is the System Regional Settings that apply here - you can find out more about this by searching this forum for ‘code page’.
So there is noway to prevent these problems. I have the same problem with a barcode 128 font. I need to set the first and last character to Ì (Ì + data + Ì) but if I understand you correctly when I compile the codeunit and send it to the customer it will change again!!
just set the correct code page when you export the objects.
What do you mean with “when you export” Will it never change then?
Bump…
I think i undertand what David try to explain to you Erik When you export to .FOB file, all const values are coded using OEM characters set. (all the characters if you use an .TXT file export) Windows API AnsiToOEM and OEMToAnsi functions use different table of correspondance According to the code page. for example : Ansi Windows Ì = alt 0204 become character code in .FOB file - 222 in OEM Code page 850 - 205 in OEM Code page 1250 or 1252 and so on If you export .FOB with a code page different than the code page you use to import (two differents stations or installations), you could have : 1) export with CodePageX : AnsiChar Ì become in your .FOB an OEM char coded (AnsiToOEM) 2) Import with CodePageY : OEM char coded in your .FOB become AnsiChar  (OEMToAnsi) In french, we say ‘CQFD’ [:)] See Microsoft Knowledge about that Good luck
Robert and David solution is the best → change the code page. But if you can do that Just one tip you could use with all windows version : On Station 1 - export object using .TXT format - With WORDPAD, open xxx.TXT by selecting MSDOS text file format - save it and select Text file only format to have it with Ansi character On Station 2 - With WORDPAD, open xxx.TXT selecting Text file only format - save with WordPad and selecting Text MSDOS text file format → to have with OEM coded - import it in Navision (you can also search a tool to download or create a little program in VB to convert) However, if the purpose it’s just send to a printer a sequence like … ‘Ì’ + Data + ‘Ì’ try to code this : Code222 Char Code222 := 222; … STRSUBSTNO(’%2%1%2’,Data,Code222) … there would be no conversion on import/export [:p] I hope this can help you
Patrick, here you are trying to make an ANSI code page (e.g. 1252) a reliable middle-man between two different OEM code pages (e.g. 437 and 850), to act as a converter between them. There are problems doing it this way. Some characters have no correct mapping from an OEM → ANSI direction, or from an ANSI → OEM direction. So a character can be changed in either of these conversion steps. The only reliable way is to ensure that the OEM code page on both machines is the same.