>We have a DBF table with 3.6 million records, about 1.6 GB. The FPT is about 1 GB. The file unexpectedly would not pack. We were very concerned the file was corrupted. However, seems not corrupted and by splitting to two files 50% each, packing and merging, the entire file now seems to pack OK. Is there any logic in this?
>Thanks if any one has a clue.
>(Incidently, wonderful VFP runs extremely well at this size. One of the table, smaller is GB has 5 millions records.)

Have you checked if there might be an antivirus involved? I have occasionally run into situations where code such as:

USE sometable
COPY TO someotherfilename
USE someotherfilename

would fail at the second USE statement, but if I'd insert a WAIT WINDOW, some form of I/O, or a DOVENT in between the COPY and subsequent USE statement

USE sometable
COPY TO someotherfilename
DOEVENT
USE someotherfilename

the problem would go away. I would guess that the inserted statement causes the FoxPro program to release its timeslice, thus giving a greater chance for the antivirus to complete the scan before control reverts to the FoxPro program.

I'd seen that in situations such as this, PACK is likely to fail -- because of the implicit file copy, file close, file erase, file rename, then file re-open is being interrupted by the antivirus (which probably opens the file exclusively). At least that's my interpretation, given the typical symptoms I'd seen -- where the DBF file ends up missing, but there is a file in the same directory with a random-looking filename that appears to the missing file.