David,

Is it possible that there's WRITE cacheing on the server's DB HD?... or even on workstations? I don't know anyone who trusts that stuff and turning it OFF seems to be pretty much universal.

I recently had a problem where network adapters had 'sleep mode' set on at factory (all DELL systems). a sudden short-term sleep might do who knows!?!?

Finally, long ago and with a different NOS (Novell 3.11) we had daily index corruptions. These were real. We had the most expensive server available at the time, a Tricord model XXX. Turned out it had never been 'certified' for Novell. Changing to a clunky sounding (by comparison) Compaq ??? pentium 90 with 256MB and a 20+ drive RAID array solved that one nicely.

One more thing... I wonder if older OS' on workstations might have some compatibility problems with latest storage/locking scheme of 2003 server.

good luck


>>>>>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.
>
>We can rebuild the tables and the problem recurs immediately. With no increase or decrease in severity. That's why I'm pretty sure the index itself isn't corrupted. The most common line of code that triggers the error is on the "locate" command ...
>
>

Use <table> again alias <alias> order <neworder>
>locate

>
>This code is in our "TableOpen" function which is a "stack" mechanism allowing table reuse (a FPW 2.6 artifact)
>
>The table is bigger (in terms of records and index tags) than most other tables in the system.
>I'll check for bad characters too, but you'd expect the thing to fail more often if there was a persistent data problem.
>I'm going to put a
>

try
>   locate
>catch
>   sleep(300)
>   go top
>endtry

>into production to see if that alleviates it.