Mike,

This is strange behaviour for PACK, to say the least, because PACK actually copies the table first, then does a quick rename. If you run it without clauses then the same (as I understand things) applies to the .fpt and .cdx too.

Since the .DBF has disappeared, it suggests that the problem is occurring at rename-time.
I have no idea as to how VFP names the 'trial files' (the ones to be renamed once things have run OK) but it might be worth looking around to see if such a beast exists. I would assume the same directory, but that wouldn't be mandatory I suppose.

I don't know what could foul up a rename - especially one (or more) working OK and the one on the .dbf not working.
What OS/SP is the server running?... Are there any known problems with renaming files on that service?

Sure is a terrible situation, and I wish you good luck in resolving it.


>I have a VFP7 client application running on about 3 PCs (W98SE / WXP) against a shared VFP database located on a server within a large client network. Occasionally one user will run a program within the application to pack and reindex the data files within the database. To do this, of course, they request other users to sign off and then acquire exclusive use of the database and tables. The routine checks for exclusivity.
>
>Recently, this has caused several C5 crashes, probably at the program line that contains the command 'pack'. Upon then looking at the database, a dbf file has vanished (leaving its cdx and fpt files). This is at the least inconvenient(!) - at the most, potentially disastrous, as the system feeds the main factory trailer loading pallet picklist.
>
>It is possible that at the point that the routine is run, there is a mismatch between the cdx file and the dbf file (how can this happen?), but I am not sure.
>
>Any ideas?
>
>Mike