>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.
>

I was clearly reading too much into "SET INTEGRITY" - maybe it should be named "SET DETECT_ORPHAN_INDEX_ENTRIES" instead. If we limit it strictly to the problem your code outlines then sure, such a setting could alert users of an index problem.

What I was pointing out was not the case of a filtered index, where we can expect table records to not appear in the index, but rather the case where a table has a record added but the index doesn't get updated. Most often due to WS, network or server hiccups and the fact that local and network file systems are not transactional. While AFAIK I have never encountered your error, I've hit mine far more often than I'd like. This is the "false negative" counterpart to your "false positive" example. I was thinking that anything named "SET INTEGRITY" should naturally handle both problems.

>>
>>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.

By "all bets are off", I meant that even in the case where VFP can still open the index, a "mostly OK" index is still unreliable, and that means it's really no good at all.

I was under the impression you would want to get VFP to delete the orphan index entry if detected, rather than rebuild the index entirely. While this could be done in a multi-user environment without exclusive use of the table/index, I agree that as soon as *any* corruption is detected, a complete index rebuild is preferable.

>
>
>
>>
>>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.

I mainly threw this question out to point out that network file systems are complex, and that someone (probably on the Fox team) would need to go through all possible lock and cache scenarios to make sure false positives wouldn't occur.