>>>Hi Sergey,
>>>
>>>Keep in mind that VFP7 and earlier versions have the same problem with index (when SET REFRESH setting is to big, the cached part of the index can become so outdated that it doesn't match the table and can not be safely connected to the rest of the index), but don't report an error. Is it what you really want?
>>
>>Hi Aleksey,
>>
>>You don't expect me to answer this question, do you? :)
>>I belive that current VFP8SP1 behavior still a bug because VFP reports index corruption in case where there is none. It should be handled by VFP internaly by discarding current read buffers and reading indexes from a disk or some other way. Right now there's no reliable way to prevent this bogus error from happening besides maybe putting SYS(1104) before any VFP command that can use indexes.
>
>Hi Sergey,
>
>My point is this - the fact that VFP8 reports an error in this scenario is not a VFP8 bug. The error just exposes an old problem that was there for a long, long time. So, don't kill the messenger. :-) The error wasn't added to VFP8 to address this particular problem, it was added to address a real on-disk index corruptions (that should explain the text of the error message). The in-memory index corruption wasn't known issue until we investigated a couple of cases when the error seemed to be reported false positive and confirmed that this is the case. When the issue is known, it is half way to be fixed.
>
>Thanks,
>Aleksey.

Just to clarify what does " false positive " mean in this scenario. It means that index on disk is OK, but whatever is cached in memory is not OK and it can cause many bad things to happen. It is not like the error is reported whereas there is no any problem.