The file has to be readable of course in order for the data to be appended to the newly created table. Most often, foxfix can fix the table itself on the fly, that is why I like using it. For over 90% of the cases, Foxfix fixes the corrupted table on the fly onsite at the customer's location. Foxfix has a dll you can load in your app that when called will verify the table before opening it in VFP and that is how we do it. I know others like to use SDT...

>Thanks for responding Tracy. Assuming FoxFix didn't handle the file and assuming that the empty data structures are written, how does your program to read data know that it is reading something right? Or is it just a blind reading from the given header end point for each and every records lengths? What about memo data?
>
>>We use foxfix. If VFP cannot open the table, Foxfix scans the table on the fly and if possible, repairs it. If foxfix cannot repair the table, I rebuild it from scratch (we have a program that retrieves the table structures of all of our tables in a directory and we wrote another program that builds the new table and reads in the data from the original corrupted table). The problem is when the table is corrupted to the point that foxfix cannot repair it or we cannot read the data to bring it into a newly created table. When that happens, they have to send the file to me so I can repair it manually using foxfix.
>>
>>
>>>Hi all
>>>
>>>Corrupted tables is a way of living <g>. But how to detect that a table has been corrupted.
>>>
>>>Today I worked on a corrupted table, I indexed it. I closed the financial year with such a table. The user had data-entered in other table for a few days without noticing this tables problem becuase he had not required to work on it.
>>>
>>>How can I detect that a table has gone bonkers.