>This works well unless the excel file is marked for a codepage that is not supported by the computer doing the conversion. In this case, excel will replace any characters other than the lower ASCII with a "?". There is also a bug in the support for multibyte languages (Chinese, Japanese, Korean).
>
>For instance where "A" is a lower ASCII characer and "#" is a multibyte character:
>
>a1 = "AAAAAAAA", a2 = "####" : Excel 97
>
>converted on a machine that does not know how to handle the codepage
>
>a1 = "AAAAAAAA", a2 = "????" : Excel 5.0
>
>converted on a machine that does know how to handle the codepage
>
>a1 = "AAAAAAAA", a2 = "##AA" : Excel 5.0
>
>result of append from
>
>a1 = "AAAAAAAA", a2 = "##" : Foxpro
>
>
>Apparently, Excel uses a buffer to read in and then write out each cell. After cell A1 is converted, the buffer contains "AAAAAAAA". The function that copies from the cell into the buffer is told to copy 6 characters, but copies 6 bytes. The string length is written as 6 characters. Foxpro uses COM to convert the file. The dll that handles Excel files makes the same mistake again. This time the strings are zero terminated and only the truncated multibyte characters are in the Foxpro table.
>
>Thankyou M$ for making international language support so challenging.

We don't use any high-asciis in Excel, but that could be Marc's problem...