Problem: Client's server crashed during a table rewrite, left them with an 800Mb temp file ... and client had NO backup EVER. Initially a DIR showed the temp file with zero records but 800Mb, thus, I ran Abri's Recover to fix the record count in the file header. This corrected the count which now shows up in DIR, but when I try to open the table, only then do I get a 'Not A Table' message -- NOT when I do a DIR, as normally also happens with a corrupted table.

I did go the second step in Recover and created a file recovery template from a known good copy, but found on viewing the data that apparently the temp file structure is 'subtly' different from the source file, because the data don't line up with the fields. It does look like a consistent offset, though!

Questions:

1) Any insights as to what's wrong with the table that it still shows 'Not a Table', and how to fix it?

2) Vast areas of the data are definitely intact. In the worst case can I pull it in using lowlevel file reads, parse it, clean out any crap and put the table back together? What ASC(nnn) should I be looking for as the record delimiter? (It seems to me given the possibility of file damage, my recovery effort would likely get better results by looking for this 'landmark' instead of just counting bytes.)

I'm handy with the lowlevel stuff but have never specifically tried parsing data out of a DBF.

Thanks much...