>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!
>
Well, from all descriptions, you made a cardinal error - you tried fixing things in place. Rule # 1 - if you ever have a crash and there's no backup available, the very first thing to do is to make an image backup of the drive that preserves the supposedly empty areas of the partition, to make damned certain that if you have stray clusters in free space, you have an exact record of the physical layout of the partition when it was detectd as broken.
Second thing - I'll bet they still haven't bought a backup product yet. Unless you like being bald and bleeding on your pillow when you finally go to sleep, tell them you won't touch the damned thing until they've got a backup product on hand so that you can work, safe in the realization that your efforts can't make things worse than when you were called in.
>Questions:
>
>1) Any insights as to what's wrong with the table that it still shows 'Not a Table', and how to fix it?
>
The "Not a table" error indicates that there's something fundamentally wrong with the DBF header - it could be any of a number of things related to the header, checksums, and delimiters in various parts of the header.. I'd recommend picking up a copy of a commercial DBF repair tool like FoxFix (what I generally use if things are really bad and I can't get backups; I'm a real stickler with my clients about backup procedures) or dSalvage Professional (I've never used it, but know a couple of people who do use it and like it.)
Do not try to "cheap out" the repair - the more you dink around trying to avoid spending a little money for a decent repair tool, the less likely your chances of ever recovering the data becomes.
>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.)
>
FoxFix can be helpful in recovering this data if you can reconstruct a valid header for the file - it can help you 'line up' the shifted data and move it into the new copy. A very strong hint - when you do this, amek sure that your write target is on a separate physical disk drive - the cost of a 20GB IDE drive now is so low that it's foolish no to buy a fresh drive to work with, in case the original drive is damaged in some way.
>I'm handy with the lowlevel stuff but have never specifically tried parsing data out of a DBF.
>
Unless memo fields are involved, the data is all fixed-length records once you get past the header. Memo or General fields complicate the issue, in that a separate FPT file holding variable length data is involved, and Fox stores offsets into the FPT in each record, for each memo or general field.
I'd also count on any structural CDX information to be questionable as far as reliability - if you do succeed in recovering some or all of the data, I'd suggest rebuilding the indexes from scratch.
>Thanks much...
Just make sure before trying anything more that you get an image backup...
