>>Though VFP can use one codepage at a time, it can make that time really short, i.e. nowadays every control which has .font* properties also has a .FontCharSet property, which can interpret the string in whichever way you like. So you can't mix codepages inside one control, but you can have multiple controls, or you can flip the codepage as needed. You only need to store the strings with NOCPTRAN and to know the applicable codepage - which would, I guess, be stored somewhere in parent tables, one per country or region. So just add a .fontharset=lnCharset in the .refresh() of a control, and it will display in the new codepage. You can flip from Western to Central European to Turkish to Baltic to Cyrillic to Greek to Chinese in less than a millisecond.
>>
>>Converting toponyms into Western codepage is an invitation to disaster, which can hit at random. Unfortunately, I can't show you any examples, because the current incarnation of UT is guilty of the same error (it was UTF-8 in VFP/dbfs, which were somehow more capable of handling multiple codepages than the current dot-net-sql implementation, which is mostly world-illiterate).
>
>Dragan - very interesting and enlightening - I need to study it further - but I do need to store them as converted because the data will be used alongside the postal information of other countries, and used in the main by people whose IT skills are not great
>
>It will also be bolted into other systems over which I will have no control - so the data has to be seen to be correct

In that case I'd rather have the data in some other data store capable of storing DBCS or (preferrably) UTF-8, like Sql Server or MySQL. You can convert from local codepage to a wide set using strconv() when composing the insert command. I know I've done this once (long ago) for MySql and after a few bad starts I got it right. That way everyone will see it properly, with no conversions down the road - only your initial conversion from native codepage to a wide set.