>Aleksey,
>
>I was intrigued that you mentioned "...during END TRANSACTION..." because the VFP8 Help for SET TABLEVALIDATE... does NOT describe this "limitation" - it suggests that the checking is done for ALL INSERTs and APPENDs.
>

You misinterpret my answer again. Sorry, may be I wasn't clear enough.
In VFP8, check during END TRANSACTION is performed regardless of the current TABLEVALIDATE setting. This check is not a header check, it is a check to make sure that appends are not going to be lost. This validation can not be switched off. And it is definitely not a limitation.

>I ran a variation of the 'test' included in the MSKB article Q293638, removing the BEGIN/END TRANSACTION statements. With TABLEVALIDATE set to 2 or 0 I got NO ERROR which is exactly as you suggested!!!
>
>While this shows that, at least, the Help needs "clarification", the bigger issue to me is WHY is the additional check limited to TRANSACTION processing ONLY???
>

I've checked the help topic about SET TABLEVALIDATE - it is correct.
2- Validate record count when appending or inserting records and writing them to disk.

One detail here is that the check is performed not at the time the APPEND is executed, but at the time when that append is saved to disk (exactly what the help says). In exclusive mode there can be some time between those two operations. If you still think it doesn't work, please, post a repro.

>I cannot see performance impact as being a serious reason because I would imagine that Window's caching/opportunistic-locking/data-coherency strategies pretty much ensure, in a multi-user VFP application environment, that the file attributes and the table's header record are virtually always available from cache.
>

Unfortunately, header check is not limited to reading the header, some additional operations with the file are performed and it does affect performance. That is why there is a way to switch TABLEVALIDATE=2 off.


Thanks,
Aleksey Tsingauz.