Geoff,

>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'.

Could you provide a clue on where to find this ?

You could be right here, with one exception : Records just can be added. So, it's at the overflow of a block which makes THAT block corrupt, and in the new block all is right and records can be added there (forever). Like I said earlier : if the corruption isn't noticed, the corrupted blocks ends up in the middle of the file somewhere.

Now I think of it ... when the corruption is discovered, this is never by means of some error; I mean, all data is approached via an Index ever, and there's just an unexpected EOF() occurring;
I never thought of this before really, but it implies that the nulls would be in the index too, right ? Actually this is true and I should have noticed it more explicitly before, because the first thing to do at checking whether "it's the thing again" is to have an (any) index active and perform a Go Top. This always shows the null records at the top nicely.

So hmmm, this is new info to myself, and I must think this over in order to have a possible new light on this.

>
>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.

Nothing added ? or "blanks" 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.

Hmmm; In fact we are doing it all the time like this, where an SQL - INSERT appends the key, and at a later stage the data is replaced into the record. However, this surely doesn't apply to all "appends" (i.e. we use normal Append Blank just as well).
Further, I (sadly) can't judge this now, because I cannot find the article.

>
>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.

Interesting in fact. Supposed it's possible to read the long-threaded story in the re to Cy I just did, I may come to some other conclusion according that story :

1. A normal (hex) editor shows nulls, as they in fact really are in the block.
2. The Browse does too, but at a reload of the data (Refresh) it obtains the original content.

What would be the difference between the editor and the Browse ?

Right. The Browse being able to interpret the the offsets implied. Now what ?

Since the browse always shows the last records as they really are, I can't draw any new conclusions (just removed some 60 lines to prove something).


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

Agreed, but I couldn't prove it to fail so far (with proper settings).

>
>Geoff

Thanks Geoff.