>Gentlemen
>
>Thank you for your thoughts.
>
>Fabio, I have thought about going down the SQL Server route, but in the short term this isn't practical for me. In the longer term I think I'll have to do this.
>
>Tore: thanks for the lateral thinking - I like this approach a lot, and I'm convincing myself that this indeed is the best way to solve the problem. I might even enjoy the coding so that the users have a recovery path if it happens again!
>
>Jim: my impression is that the crash happens before the file is copied - it seems to happen too quickly for the files to have been copied first. I assume that what is copied is non-deleted records, not the whole thing, and that if the cdx file has become corrupted in some way then the use of this causes the crash - while the file is still open. I take on board what you say, however, but 9 times (more, really) out of 10 the process runs without problem.
>
>Thanks again.
>
>Mike

Mike. I just wanted to add that the contents of this thread leads one to think it is a VFP issue. However, packing files is done all the time by thousands of VFP apps, on large and small files, across all versions of Windows, and on standalone PC's and networks, all without issue. You say "probably" the pack command and "recently" this started to happen. I suspect there is actually something else at play here and that you should investigate the whole issue further. eg;

1) does it happen on all/any pc's
2) is there other software installed that might have an effect
3) are you using any dbf utilities which may effect the pack process
4) have you identified the exact line it occurs on. ie. is it really the pack command
5) could it be network related ie. network cards etc
6) where is the temp folder set to
7) is there sufficient disk space
8) how big are these files
9) what else is running
10) does the app use any third party tools/ocx/...
etc

I think it requires more investigation before trying to implement a work-around "solution".

HTH