>>>>>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?
>>>>
>>>>If I'm no mistaken, the FPT file doesn't contain "backlink" to the record in the DBF. Additionally there is no "deleted" tag in the FPT file to distinguish between actual data or data that has been "abandoned". When you update the memo data, unless the new data fits within the already-allocated block(s) new data block(s) are allocated to store the new data -- the original data remains (with no reference to it from the DBF).
>>>>
>>>>IIRC the PACK is performed as follows:
>>>>1. Create temporary file(s) to contain the data to be preserved -- on e for the DBF, the other for the FPT
>>>>2. Scan through the table and copy records that don't have the DELTED() tag set to the temporary file(s)
>>>>3. Close the DBF/FPT and the temporary copies (now containing only the non-deleted records)
>>>>4. Delete the original DBF/FPT
>>>>5. Rename the temporary files to replace the original DBF/FPT
>>>>6. Open the new DBF/FPT
>>>>You probably ran afoul of an antivirus and the process failed around step 5 -- probably because an antivirus or similar security program was trying to scan the contents (thus preventing the rename). You might still find the temporary files used in the PACK operation to recover.
>>>
>>>Thanks for the info, indeed based on the steps that scenario seems to be the most likely. I did not find anything in the temp, so I wonder if that file was removed from local temp after closing VFP. Strange thing is, that on the server UnDelete did not detect deleted files. So it's quite awkward, especially since the admin forgot to include that folder in the backup scheme.
>>
>>You may want to check in the folder where the original DBF/FPT were located for those temporary files.
>
>These temp files would have been created in the location specified in the config.fp file. If he doesn't have one of those then it might be in the c:\users\[username]\MicrosoftData (or something close to that) directory

What I describe is based on what I'd seen -- PACKing a table will generate a "temporary" (actually a misnomer -- "working copy" might be more accurate) in the same location as the original table. In the situations where the PACK ended failing and as a result the original DBF/FPT files ended up missing, there also appeared to be a set of files with "gibberish" filenames - which appear to have been the "working file" containing the data I was looking for. I'm guessing that it's done this way to avoid having to copy this "working file" (if created in local temporary folder) back out to the original file location, while creating the "working file" in the same location as the original DBF/FPT allows the replacement to be handled with a simple rename.