>>>We continue to get an increasing number of these errors over a period even though the index is not corrupted...
>>>Error: 2066 - Index file "h:\ht\quids\data\jitems.cdx" is corrupted. Please rebuild it.
>>>
>>>The table has approx 2.3 million records has 8 index tags including one on deleted. There are only 200 deleted records. There are large numbers of transactions on this file every day, perhaps 50,000 or so. It's not that huge in terms of disk space, 470MB for the dbf and 95 MB for the CDX.
>>>
>>>300 users, and we get perhaps 20 errors per day.
>>>
>>>Any ideas folks?
>>
>>By "rebuild", are you simply REINDEXing, or are you actually deleting/recreating the tags? The former won't fix subtle corruptions.
>>
>>One relatively painless way to "recreate" the tags is to overwrite the production .CDX with a known good one (even if it's old or has no records), then REINDEX. This can save some pain that can occur with DELETE TAG ALL if you have relations or other RI defined on that table in a VFP database.
>
>We completely rebuild the indexes. The index isn't corrupted. The error message is in error. Fox must be struggling to keep the index updated for some reason.

Hmm... I can think of only 1 way to be sure the index isn't corrupted. That would be to:

- save a copy of the "corrupted" index
- completely rebuild the tags
- Run the command-line FC command against the "corrupted" and "fixed" .CDXs. If they are identical, the "corrupted" one wasn't.

If it passes this test, the next thing I'd do would be to scan the table for bad characters e.g. CHR(0), low or high ASCII, etc.

Other than that, the next steps would be to check hardware/network connections, and caching and oplock status on server and workstations. If you're only seeing this problem with one table then I'd say none of these are likely the problem, unless JItems.DBF/.CDX are much larger than any other tables/indexes your app uses, in which case caching might be an issue.