Hi Doug

I'm not being clear. All I'm talking about is to detect a particular type of damage. I'm not talking about scanning the entire index or having the index check itself.

LOCATE and SQL are already checking the indexes and the table, if not, my repro code would have shown record "E" because it found the record pointer for record "C" in the index. VFP didn't show the record at all.

On the other hand, seek did find the record.

In these cases, it seems pretty easy to give an error message if the developer turns SET INTEGRITY ON.

>Hi Mike.
>
>>Maybe we need a new SET command. SET INTEGRITY ON? With SET INTEGRITY ON, would it be reasonable to update the index with the data from the table when there is a mismatch?
>
>I did some testing several years ago and found that trying to detect index errors just aren't worth it. Because there are so many things that can wrong with an index, it isn't possible to detect some types of damage (asking a damaged index to identify problems in itself is like asking the police or politicians to investigate their own bad conduct <g>). Also, even searching for the kinds of errors we can detect takes way longer than simply rebuilding the indexes. So, my rule of thumb is that if you think there's a problem, recreate the indexes.
>
>Doug