Peter,

My reference was to KB Q293638, from Gatheth's KB list on the Wiki, and not to the UT threads last year. There is another KB article, much older, which was useful in corrupting/repairing the header, but I have mislaid my reference to it.

When the header is corrupt, no new records are added, and there is no error reported. It's easy to reproduce, as I suggested.

As to flushing, I simply meant committing the new record (blank with pk inserted) to the table, ie tableupdate(). If it cannot be found with a seek(), then it's a safe bet the header is corrupted, at least in my experience.
When I have been able to see corrupted tables (other than by deliberately corrupting the header), often, but not always, the last record was a byte or two short. That makes the table invalid, and is different to where the header count goes out.

I have also experienced other corruption, where a record way back up the file is overwritten by a blank record or by garbage. That I believe falls into the category of memory/network and OS, which everyone has talked about regularly.

>>To be on some safe side : I've been around with Vlad for a couple of hundred emails and more, and in fact I can't believe that I won't believe him. >>

I am not trying to win an argument with you or Vlad.

>Assumed that the message was that the table header isn't updated when someone performs an Append Blank -> bull. If that were the case (for the sake of logic), Fox wouldn't work at all.
>

True. But if you take a look at he XCase specs, the header count is used to determine where the next record will be appended. The memo files and the indexes use a similar mechanism. The data engine has to have the correct value. Depends on the locking, doesn't it. Of course, we cannot be sure with VFP just what the locking/unlocking sequence is. My bet, after looking at the way is is done in Codebase, is there are one or two weaknesses. But that's just my guess, and Ken said that changes to the engine are not on the agenda for VFP8, so I guess we may have to live with it.

>I guess "you" are all looking at this from some complete wrong direction. I mean, yes, if PC1 adds a record, and PC2 performs a Reccount(), is indeed doesn't show the proper count. But don't get bothered by this, and don't get mislead by it ! It just needs the proper command to enforce the re-read of the server, as (for example) the Append Blank does this itself internally.
>
>Again, without this nothing would work.
>It doesn't need a Flush and it doesn't need a Close data or whatever, which btw doesn't even help !! (test it !). >

I did, actually, in solving my problem. With buffered files you have to flush (read tableupdate() ). Otherwise, the new record only exists in the user's buffer.

Peter, of course Fox does it, and on occasions it gets it wrong and forgets to report that it found an error.

>By no means I am saying that header corruption doesn't exist or is foolproof. The only thing I say is that the discussion with Vlad doesn't touch reality.
>

So Peter, if you are not losing data in the scanario I have outlined, and are concerned just with pure data corruption, you might have to accept Vlad's advice, and accept it as a fact of life? :)

Geoff