LOL! Just banging on the bars a bit, Jim. Take it easy. I sympathize with those experiencing the problem - I'm presently chasing an aberrant TABLEUPDATE in one table in an app that I cannot duplicate - and the users unreliably :-) Fortunately, not mission critical data. I suspect the bug to be me, for not trapping those users. Just discovered last week they are using the invoicing module as a calculator - got to love them.

>Silly me for putting credence in the very first word of the article - "FIX:".
>
>And I've gotta believe that the average reader would equate "corrected" with "fixed".
>
>Since the "correction" is to generate an error (rather than continuing processing without loss of data), would that qualify as a "correction" to you?
>
>What I'm hoping to get is a reproducible situation OR a situation so fully documented that the cause becomes clear and it can be fixed.
>
>
>>Not to be a pain, Jim, but:
>>

>>STATUS
>>This bug was corrected in Microsoft Visual FoxPro 8.0.
>>

>>"Corrected", not fixed.
>>
>>>Bonnie,
>>>
>>>This looks VERY much like the elusive problem described by MSKB #293638 and presently reported as "fixed" by VFP8. I should add that it has been reported here as occurring outside of TRANSACTIONS too.
>>>My view is that VFP8 does NOT "fix" it, but rather "traps" it to assist in preventing loss of data.