Was it VFP 7 or VFP 5 that stopped erroring on header coruption?
In any case, I was asking what was wrong before that?
MSKB #293638 states that the TRANSACTIONs problem was fixed in VFP 8 - I don't know if the fix was SET TABLEVALIDATE, but I think the header checking was better the way it was in FOX 2.6

>What was wrong was that VFP7 apparently STOPPED erroring when the header count was out-of-whack!
>
>So SOME people - especially using TRANSACTIONs - were LOSING RECORDS without ever knowing it (until, of course, a user complained or had some problem).
>
>
>>I don't know...
>>Talking about my example, we never add or insert records to that table in code, and then tablevalidate 2 means no validation. If the record count is all that tablevalidate does, and the header can only be corrupted during add/insert, I guess that would be ok.
>>What was wrong with the way this header validation worked in previous versions - i.e. you got an error when trying to open a table with a broken header, but did not get an error when opening a table that was locked, unless yoy wanted to update it?
>>
>>>Doru,
>>>
>>>Does SET TABLEVALIDATE TO 2 not get around this problem for you?
>>>
>>>>Hi Tom,
>>>>I see you smile when declaring this a feature...
>>>>I think the handling of table validation with SET TABLEVALIDATE has a flaw in logic: It assumes that it can always lock the header of the table, and if it can not it assumes that something is wrong and generates an error.
>>>>
>>>>Consider this, real life, scenario:
>>>>We have table that must updated from one computer only (a data logger app.). The table is valid, so we have no problem opening it and issuing a FLOCK() on the designated computer.
>>>>We need to open the table read-only in many other applications – but, if we want the so called TABLEVALIDATE feature enabled, we end up in an “Attempting to lock…” and an error “File in use by another user”. The error affects the entire MIS Applications system, now the only option we have is to disable the table validation.
>>>>
>>>>I believe that the correct behavior is that if a table header cannot be locked TABLEVALIDATE should not generate an error, in other words, should assume nothing and do nothing.