>>>- with bells and whistles: figure out the untouched memo blocks in the memo file, list them for the operator, possibly he can identify missing data.
>>
>>>But I thought there was no backlinks in the FPT to point back to the DBF record who owns it? In cases where the FPT pointers in the DBF are corrupted (or the pointers are fine but the content of the FTP has been corrupted) how can you parse the FPT and "know" what DBF row that chunk belongs to? Apologies if my understanding of the internal structure of DBFs v. FPTs is incorrect.
>>
>>The memo comes in blocks of a size you find at byte 06-07 (SET BLOCKSIZE at creation time.) The blocks start at byte 512. The length of the memo is at offset 04, so you can calc how long a block is - and where the next one should start. A block starts with "00 00 00 00" or "00 00 00 01". If you do not see this at a block start, this is no block start, you are on a consecutive block.
>>
>>The memo field inside the DBF points to the start of the block. (for all I know, it's a virtual number, the position is number*blocksize+512) So, just read the blocks that the DBF defines. Do not read blocks defined by the DBF that do not start with 00 00 00 00 or 00 00 00 01. Those are bad by definition.
>>This does not solve corrupted pointers in the DBF and data not written to the fpt, but most data.
>>
>>As you see, you could also read the fpt first, store each block with it's number and resolve the DBF. The would allow to even store wrongly overlapping blocks, because there is a chance that the block start is no block start but binary data in the middle of a block.
>
>Thanks, Lutz. Appreciate the insight!

The structure of DBFs is stuff from the 80s, so not much magic there.
Help topics "Memo File Structure (.FPT)", "Table File Structure (.dbc, .dbf, .frx, .lbx, .mnx, .pjx, .scx, .vcx)" and "Visual FoxPro Data and Field Types"; reading a fpt and a dbf using a Hex Editor. :)
All you need to figure out is the byte order of the values, the remainder is counting bytes in both files.

Note that width of a record in the DBF owns a number of bytes to mark Deleted, the VAR* fields and the Nullables, as far as I know this is variable due to the number of such fields.
;)