Hi David,

Try to delete the DELETED() Tag. The LOCATE Statement is rushmore optimizable and probably is related to the problem.

Walter,



>Hi Walter,
>Yeah, we're thinking of ditching it. Problem is the deleted count sometimes goes up to about 20%, ie several hundred thousand records, because we run live archiving. We don't have enough down time. VFP 9 also has a new faster binary index for this stuff, which we'll have a good look at.
>You can look in the other threads for what I think is the best solution. Essentially the error pops up when we
>SET ORDER TO
>LOCATE && to quickly "go top"
>
>We've rebuilt the error handler to retry the locate after doing a SYS(1104). We're hopeful that'll help. Goes live next week.
>
>>Hi david,
>>
>>First of all, try to remove that index on deleted(). It probably is only slowing your queries down (Large number of records, only few deleted). That index is absolutely useless in a case you don´t use the COUNT function.
>>
>>Second, I´ve seen numerous cases where an corruption error was raised, because some obscure unidentified bug in VFP. It was reported in a fresh cursor with an index on it. There was no way this index was corrupted. It was caused by the gui where a grid was involved. I never was able to get a reproducable case to send of to MS.
>>
>>Walter,
>>
>>
>>>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?