>>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.
>
>There was another workaround, which helped in those cases when
>- user A creates a new record
>- user B creates a new record
>- user B saves
>- user A saves and overwrites B's record
>The workaround was to call Reccount() immediately after the tableupdate(), which somehow forced the header to be updated with the correct record count. May as well work in other cases.


Now wait a minute here ... (and referring to my re at Geoffs' from a few minutes ago (about me not understanding)) :

Do we talk SQL (Remote Views etc.) or what ? That is, I see now the reference to TableUpdate. Anyway, I still think the discussion in that thread misses points, and it looks like the native behaviour of Fox is discussed. Thus, putting in between there all fuzzy stuff like RV's, I can already ensure that nothing works properly anymore. Well, who am I to say this ...
When for a basis the remaining locking features are taken (SQL environment), AND knowing that this is the basis of all Fox's native behaviour, this is IMO not to be manipulated by something in between.

Well anyway, when it's about TableUpdates and Reccounts and Locks and Tableheaders, I am lost anyway. That is, without the proper perspective.

But Dragan, I assume your example about the User A and User B wasn't about native VFP (DML) ?