Mybe FOPEN() and break it into pieces. It seems you may need to write an archiving utility or switch to SQL for this particular table.

>>>Hi George,
>>>
>>>Thank for your help and advise. However, is there any way to remedy this
>>>problem since VFP5a and 6 indicate it as 'not a database'. I can't open
>>>it to purge the data. Please kindly advise so that I can access the
>>>data again.
>>Assure you have backups before you do anything!!
>>Help me review this
>>- A database contains tables
>>-- Are you using 'use' or open database. If this is a table (DBF) then 'USE' it to open. USE MyBigTable EXCL
>>--- If USE will not open the table it seems like a file header issue. It would be difficult to open such a large table in an editor to repair a damaged header. Norton may have a utility. If your DOS-DEBUG skills are good, you could correct the header by editing disklocations.
>>-- I think USE will open if the EOF marker is embedded before the logical end of the table.
>>If you can use it, and browse it - you can copy it in sections to other tables.
>>Look at the ATTRIB in it's directory
>>what happens with a lowlevel open:h=fopen('MyBigTable.dbf',0) - is an error returned?
>>Tricks if you can USE:
>>copy structure to NewBigTable
>>USE NewBigTable
>>append next 100000 from MyBigTable
>>or
>>COPY ALL TO MyBigTable2
>>Let us know how it goes.
>>SANDISK?
>
>Hi,
>
>Thank for the help and suggestion. However, vfp5 cannot open
>by reportiing of 'not a database file'.
>
>Opening the file using fopen is okay and the last byte of the
>file is ETX. What do I do after that ?
>
>I had managed to use vfpview to export the
>data to a text file. I can't import it back to the
>dbf file again as it will again give the file size of
>2G again.
>
>So, what is the better way to recover the file back
>when I hit th same problem again. thank you.