>>Hey all,
>>
>>Just had a massive debacle. Was packing a table with about 90,000 records in it when the server freaked out. Got kicked out. Upon looking at the table when I got back in (it was openable, though indexes were gone), the file was corrupted in a way I have _never_ seen before or thought possible. The file actually had data from a _different file_ in it, a file in a completely different part of the file hierarchy (though on the same server share).
>>
>>I know this sounds impossible, but in looking at the data both in browse view and in a text editor, it is clear there are chunks of data in there from a completely different file.
>>
>>We have a theory: what crashed our server was likely an open file backup agent which allows backups (Arcserve) to back up open files. Could the agent have been messing with the file at the time of packing (backups were not running) and got the file extent pointers all mixed up or something so the file actually morphed into diferent pieces than its own? This is whacked out, I know, but it is very perplexing.
>>
>>Another strange thing is this -- The file is 902 bytes wide. In looking at yesterday's backup, we discovered that there were 484 recs added today. When comparing yesterday's file to today's (trashed) file, the trashed file is _exactly_ 902*484 bytes larger. I suppose that could be reporting from somewhere else in the file system other than the actual file, but how can a file that is cleary trashed beyond recognition still report to being the exact size one would expect. This is all just too weird, and it is truly terrible since we are now 484 claims behind and have no hope of pulling the data from this garbaged file.
>>
>>Has anyone seen _anything_ like this before?
>>
>>Thanks!
>>
>>Joe Kaufman
>>ENCOMPASS Health Mgmt. Systems
>>jkaufman@encompas.com
>
>Hi,
>
>If you're running Netware, Novell has doucmented that data corruption with FoxPro can occur under 4.x. They've said that it's fixed in 5.0. FWIW, I've switched from Client 32 to Microsoft Client for Netware, and these sorts of problems have disappeared.

Terry,

George's advice re Novell client software is well taken, but when a file server crashes while files are open it's not unlikely to result in file corruption regardless of the NOS, the client software, or the type of file (VFP or otherwise).

A PACK is essentially a COPY of all not-deleted records to a new file, so for a while during the PACK there is a temporary file being used, With luck, it might still be there and have your 484 records in it. You could look for all the TMP files with yesterday's date and see if one looks like about the right size. A long shot, but probably worth a try under the circumstances.

In the VFP3 Hacker's Guide Tamar and Ted offer the following advice:
"PACK removes all marked recors permanently. What it actually does is copy all the unmarked records into a new file and then rename the new file. Because PACK does this behind the scenes, it can be disatrous if your system crashes during a PACK.
"Don't use PACK. Instead, do the same steps yourself, using COPY TO, DELETE FILE, and RENAME. ..."

I'll be the first to admit I haven't followed that advice all the time myself, but your experience is a good reminder why we should. Good luck with your recovery.