Paul, you’re incorrect. It is not about whether the OS supports Unicode (all editions of Windows now do), it is about what a particular application supports. The OEM (DOS) and ANSI code pages represent single-byte character sets with the limitations I outlined. The Windows OS provides Unicode support, if applications are written explicitly to use it - Navision is not. Unicode solves these issues if an application is internally using Unicode to manipulate its characters. Navision internally uses OEM and is doing OEM/ANSI conversions all over the place - it is not using Unicode for anything other than interfacing to COM and the outside world. It is strictly single-byte. There is no difference between SQL 7 and SQL 2000 regarding Unicode support - they both have the same Unicode data types. However this is irrelevant since Navision does not use these Unicode data types at all (and in fact Navision does not support 7.0 anyway). What Allan is trying to do cannot be done because there is only one active OEM and one active ANSI code page on any windows machine that dictates the outcome of all ANSI/OEM conversions, using OemToChar() and CharToOEM() which Navision is using. This is why the important setting in the ‘Regional and Language Options’ of a machine is the Advanced tab’s ‘Language for non-Unicode programs’ setting. It determines the ANSI/OEM conversions as far as Navision is concerned. As I said, only those characters whose IDs are the same in two given code pages will convert, and thereby display, correctly.