SNIP
>
>I have not expereinced any CDX corruption for several years. My users are just as abusive as others. Their equipment is just as likely to fail as others. Maybe I am doing something wrong:-).
>
>SET RANT OFF

While I think you're on to something here, I see it a little differently... could an increasing usage of table buffering - especially beyond 'sensible' usage in many cases - be at the root of much of this???
We're quite confident that we know what happens to DBF data in VFP, buffering or not, but I think that CDX updating/writing remains mysterious. Does a TABLEUPDATE() write the CDX records affected too?... Does a FLUSH or UNLOCK write the CDX records affected too?... Does the OS itself handle (real) flushing of CDX records differently, just by nature of their size and the variability of what parts actually change?... Does VFP have some issue (we used to call these 'bug' < s > ) with writing CDX records when lots of records have been table-buffered?... Does the VFP itself have some problem REFRESHING CDX-type records?... Does the OS itself have some problem REFRESHING CDX-type cached records?

As regards your solution, I doubt that many people will actively restrict themselves to SEEK/REPLACE/INSERT. I do it when I can, but often I just cannot.
It's human nature to exploit newer features and newer features are also designed to permit wider applicability/compatibility for new applications.

My suspicion personally lies MAINLY in the OS and its caching mechanism and a little in VFP itself. But regardless of what is at the root, I'd certainly like to see it addressed! The incidence of CDX corruption surely is rising and its continuation is one sure-fire way for VFP to get an unrecoverable black-eye.

cheers