>Not so easy - many customers access the data using self written utilities in VFP7. This appears to cause problems when tablevalidate is not set to 0. I have much internal code checking table header length vrs physical length which appears to be the most common error with vfp tables.

Well if those people have self-written utilities, and use a prior release to do them, I'd say that doesn't bode well. Do they actually WRITE to your tables with those utilities?

Is it possible that the HD with your tables is oldish and possibly getting some bad spots on it? Or has connector problems?
Is it possible that a workstation has a bad connection?
Is it possible that a network cable somewhere is in a precarious situation like running over/under/near a motor or fraying from rubbing or ????

What is the file server OS and what OS is running on the workstations?
Have you confirmed that none of the workstations, nor the file server, have write behind cache enabled?... And that no network cards have any power management features enabled?

It has been written that VFP9 has tightened up memo field validation, so I can imagine some VFP7 program writing a memo that upsets VFP9.

Your choice to use TABLEVALIDATE at 0 seems a lot like leaving the locks unlocked at the jailhouse. A bit like someone whacking you on the head so you take an aspirin to relieve the pain. TABLEVALIDATE has as its objective PROTECTING YOUR DATA.

Good luck