Hi Al
<snip>

>Nice repro code. Just playing devil's advocate here, I think this may open a can of worms:
>
>1. Your code illustrates one problem that VFP might be able to fix. However, I think the opposite case - where there is a record in the table that is not reflected in the index - is likely to happen far more often and is more subtle/harder to find; the record simply won't show up in index- or Rushmore-based searches. In that case VFP has no obvious/simple way to know there's an error.

I never suggested SET INTEGRITY ON operate in any way except to check index entries against the data. I'm of the opinion that if the record is not in the index, there is simply nothing to be done. In a filtered index, there will be potentially many records not in the index. That isn't corruption. The index is built from the data, so it only seems sensible to worry that it is out of sync with the data, in those cases where it is relied on to get to that data.

Limiting this discussion to the scenario I outlined, how can having locate/SQL compare the index values against the records and seek (which only uses the index) compare the index entry against the actual data be opening up a can of worms? Except for a small performance hit, there seems to be little risk.

>
>2. Philosophically, I tend to think once you get corrupted files, then all bets are off. Your case plus the one I outlined above are only 2 of many different possible corruption scenarios. Just how good should we expect SET INTEGRITY ON to be?

Corruption of the index can happen anywhere in the file, potentially leaving most of it intact. In that case, most bets are still on. The treatment is still the same, detect the corruption and rebuild the index. We have no way to detect the corruption of the index. Scanning the entire index is slower than rebuilding the index.



>
>3. What about multi-user scenarios? Is it possible spurious errors might crop up because one station is adding or deleting records while another is using a search function with SET INTEGRITY ON?

Good questions.

1) User A adds a record and User B seeks.
Nothing happens, as the new entry is not yet in the index. User B would be presented with another record that matches the seek expression.

2) User A edits a record causing an index update. User B seeks the old value before the update. This could be an error. The point is, this happens today. What is the result? Does the wrong record appear? If so, does the user not see something is wrong? Do they fix the record, messing things up worse or do they call for help and end up reindexing? If this never happens now, it implies the index header is locked while the update is happening. Again, my imagined enhancement would only fire just after the seek, not during updates.

The repro code shows that record "C" which is in the restored corrupt.cdx is never displayed by LOCATE / SQL. I can't see how we could catch index corruption before the bad records are dropped. Only the VFP Team could do that.