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.

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 realize that the article is restricted to TRANSACTION processing only AND that the bug itself has only been reported in such a circumstance, but I seriously question the wisdom and value of limiting the check as has been done.

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.

What are your thoughts on this and what action do you think would be reasonable to take?


>>You do gain something with TABLEVALIDATE set to 0 or 2, just not at USE time. Later, on any attempt to write a (new?) record while the length/count discrepancy exists, an error message WILL be emitted.
>
>I was talking only about USE command. If TABLEVALIDATE set to 0, VFP8 performs some additional validation during END TRANSACTION to make sure that appends are not lost, but it is not really a header validation.
>
>Thanks,
>Aleksey Tsingauz.