>>Something strange happend: I opened a table over the network (vpn) exclusive, did some changes, issue a pack, and an error message "Table does not exist" appeared. Closed VFP, and the DBF file was gone from the server location. No other user was logged into the server at that time. The fpt and cdx files are both still there.
>>
>>I can re-create the records from the dbf from another table that has the contains the same records but without any memo fields. So I was thinking is there a way to pull out information from the fpt file and try to match those with the records from the other dbf to re-create some of that data?
>
>I once wrote a hack, aka system tool, to recover crashed tables (maybe I posted it in downloads, but can't find the link to them nowadays). It was a generator which would build a .prg which would then have to be given a crashed dbf and it would rebuild it by _blindly_ reading bytes from it and writing into a new table with the same structure. I still have it around, I can supply it if necessary, but the comments are not in english.
>
>Anyway, this blind read would basically read the n bytes required for each record into a string, then chop that string into pieces for each field, and eventually convert those pieces into actual values. So yes, I had to have bin2int(), bin2float(), bin2datetime() etc. The bin2memo() is actually quite easy:
>1) the M field in the dbf actually contains a c(10) value containing an integer. That integer is your block number. Just find that block in the .fpt (offset + blockNr*64 - or perhaps (blockNr-1)*64, or your blocksize if it's not 64), take the first (two? four) bytes to be the actual length of the block in binary integer format, and fread() so many bytes from the .fpt, write that into your memo field in the new table.
>
>Where will this fail:
>- fox wrote a new block into .fpt but crashed before writing the block number into dbf; you get the old version of the block
>- same if your dbf is older than .fpt
>- you don't have the most recent version of the .fpt, so the field references a block which is beyond eof() of the fpt, you get ""
>- you have garbage in dbf, the block number is impossibly big or (theoretically possible) accidentaly inside the .fpt but pointing to something that's not a proper beginning of a block, i.e. in the middle of another block. You get "" or garbage.

Thanks for your insights. Indeed this is kind of what I was looking for, The problem may be point #2, because indeed the dbf would be an older backup, but I suppose some of the data of the fpt could be mapped. For now this is not anymore necessary, because the information has been re-created manually. But it's good to know how that could be working. In any case the respective files have been added to the backup process!