>Hello all,
>
>We have a number of VFP 5.0 applications running off of our main data files. Lately we've been experiencing frequent (almost daily) index and file corruption and I'm trying to find the best way to track down the culprit.
>
>After reading posts here and elsewhere there are a number of possibilities, including Client32, Data Compression, Drive-based Caching on some Micropolis drives, client side GPFs, etc.
>
>So, I got the Network guys to upgrade everyone to the latest Client32 3.1 with the safest setting (cache writes off, file cache level=0, packet burst off, true commit on, use extended file handles.)
>
>I turned off Novell's data compression on any of our data files (although not universally).
>
>My question is, is there a way I can detect corruption as or soon after it happens? Is there some routine that I can run to constantly check for corruption and notify me? That way I could test various machines and operations to look for additional programmatic, client, or hardware problems. I can loop without an index to constantly check for corrupted records, but what, if any, is the best way to check for index and header problems?

There is no way you can totally check for corruption. I've seen times when it doesn't show it's ugly head for months after it really happens. One thing you can do is SEEK a particular record using different tags and GOTO . Pick a record near the end of the table. While this won't guarantee that your data/index is not corrupted, it may catch it sometimes.

Craig Berntson
MCSD, Microsoft .Net MVP, Grape City Community Influencer