>>>TYPE CSV is not valid in 5.0. So I used DELIM. The good news is that it will copy more records, BUT when I open the delimited file in Excel 2010, I still need to change field types in the open wizard. If I leave them all as GENERAL, then 'F' translates into 'False' and '03' translates into a numeric 3. In both cases I need to change GENERAL to TEXT. Rather tedious, but that's what you get when working with old versions!
>>>
>>>Thanks to you and Rick!
>>
>>
>>I missed the part about VFP 5. Sorry about that. I believe you can also save the table in a FOX2X format old-style format, and open the table directly in Excel with field names and more than 16K records.
>>
>>UPDATE:There's a trick you have to do to get this to work. On the FOX2X output file, you need to resize it to be its generated size less one byte. This removes the trailing ASCII-26 character. To do this:
>>
>>

lcFile = FILETOSTR("myfox2x.dbf")
>>STRTOFILE(LEFT(lcFile, LEN(lcFile) - 1), "myfox2x.dbf")

>>
>>Then it will open in Excel.
>
>FILETOSTR/STRTOFILE functions were introduced in VFP 6 as I recall.


LOL! Okay, in VFP5 you'll need to use some combination of fopen(), fseek(), fwrite() and fclose().

There's an old trick that I don't know if VFP honors. If you write a string of 0 bytes (such as SPACE(0)) the OS will truncate the file to whatever the current file position is (whatever the last fseek() was). There may be an explicit function in VFP to truncate the file as well, but writing 0 bytes is one way through the OS.

If you cannot do this with VFP5, let me know and I'll give you the Win32 API calls through the DLL to use their equivalents.

Update: I see that VFP has FCHSIZE() in VFP9. If it was introduced earlier ... there's your answer. FOPEN(), then FSEEK() to the end minus one, and then FCHSIZE() to whatever that position is, then FCLOSE().