I saw a post from Rich Simpson (I think) saying he had seen this. Also, I seem to recall a post from Vlad Grynchyshyn saying that issuing FLUSH after END TRANSACTION prevented or helped prevent the corruption. Maybe one of them will chime in.

Lots of folks use transactions, and we haven't had many reports of folks running into this. It would be nice to be able to repro the cause of the corruption so we could fix that, rather than trapping for it, but no one has ever provided a repro for the corruption.

>SNIP
>>
>>I sent through a note to have article 293638 updated with this information, and there is an upcoming KB article that will describe this and other data integrity improvements in VFP8.
>>
>>Just out of curiousity, have you ever run into this before?
>>
>SNIP
>
>No I haven't, but that's because I have deliberately avoided transactions since hearing of some (probably other) problems much earlier.
>
>But I now have a case where they make best sense so I've been looking through things to try to assess the current situation. So far it seems to be along the lines of you either experience the problem or you don't. There doesn't seem to be an isolated set of known factors that should be avoided, at least as far as I can glean. In some of the apparent cases it seems that the .CDX may be written OK (at least in one case where there is a report that an index mis-match message is emitted and a reindex seems to fix it).
>Yesterday I went through "Platform SDK" documentation at MSDN on I/O Concepts and Opportunistic Locks to see if there was some clues. All I could really come up with is that it looks like a dangerous (my assessment) practise to have the writing application active on the same machine as where the tables reside in a networked application. But none of the few discussions here that I find on the problem mention that (or much other in the way of commonalities other than TRANSACTIONs).
>
>Thanks for the effort at getting the article updated.