Hi Peter,

I wrestled with these issues late last year, and by chance I came across Gareth's KB article which reported the 'problem' that if records were added to a corrupted file (header count error), no error was reported. It is now classified as a 'bug'.

You might verify this in your situation, simply by corrupting one of the tables known to have the problem. I did this with a journal file which adds a record for every transaction event. With the table corrupted, the program apears to run normally, but no journals are added.

The only workaround, I think, is to add the new record with only its primary key, make sure it is flushed to disk (not necessarily with flush) and read it back to update the rest of the data.

It was a relatively rare occurrence across 50 sites and a hundred or so tables, but the work around immediately throws up the problem, and users get out and repair the table.

The reason for corruption, of course, is not simply the header count being out by 1. When the added record is short by a byte (or more), the header count will never be valid. I seem to recall that in earlier versions of DOS one could write beyond the end of a file, so that one would half expect that the problem would not manifest itself, other than an odd byte in the 'gap' to maintain the integrity of the table length. However, the Fox low level calls would not allow this, and it may be similar with the data engine.

While networking, memory and OS factors are outside our control, I am convinced that the data engine is not always innocent in these situations.

Geoff