>The problem is permanent - once the error happens it never gets corrected on it's own. If the problem were the cache wouldn't the file eventually get written?


Eric,

Not if something happened to cause the write chache to dump the write to the header.

This situation is not common in VFP. It was quite common in earlier versions of FoxPro. VFP did a lot of fixing of how and when it writes to disk and how data it will cache. The changes in VFP have greatly reduced the frequency of this problem, but it has not been completely eliminated. I suspect that there is some set of circumstances that are causing your app to suffer this problem. Finding out exactly what will not be easy.

In prior version of Fox this was the dreaded "Not A Database File" error because earlier version checked the record count on opening the dbf and refused to open it if the count was off. VFP doesn't check that particular issue any more and is supposed to correct the record count on opening the dbf. Are these systesm running on the same network software? Which net software Novell, NT? Because the way VFP checks the dbf is to compare the

(file sze - header size) / Record size TO the record count

If for some reason the server is reporting the old file size instead of the new one, that would explain why VFP isn't fixing this itself.