Lynda,

Never and I mean NEVER pack database with memo on an NT network. There are things on the server (Opportunistic Locking, delayed file writes, etc.) that are inconsistent with the pack process involved with memo files. Copy the files to the local work station and then pack them. Then copy them back up. Another strategy would be to do a select keeper records to a temp table, copy off your history records and then copy the temp back over the original file. Whichever way you go, this will save you countless headaches over the PACK command.

Use Dsalvage which has a decent Memo file fixer to try and recover. Before that thought, copy the files local and append the records to an empty dbf structure. This sometimes recovers...

Jim
>If there had been a current backup, there wouldn't have been a problem and I would have missed something quite educational. As usual, there's more to the story:
>
>The operator was short of time so she skipped the backup. In fact, she skipped the entire process last month so there were twice as many records to move to history. She started the Monthly Close and noticed it was running slowly so she began answering email on the same workstation. She switched back to check its progress several times. It was on one of these occasions that the workstation froze followed closely by the server. The task being executed at that moment was the query of 14K+ records and their memo fields into a temporary table on the local drive.
>
>Upon closer questioning, it turns out that her workstation only has 128K RAM. With Windows 2K as the OS, this memory-intensive task, Outlook, and who knows what else running on that workstaion, it really isn't much of a mystery why the workstation gave up, but I am mystified 1) how this could bring down the server and 2) why data was lost. The source table should still have been intact on the server as the query was being run.