>Hi All!
>
>In regards to http://fox.wikis.com/wc.dll?Wiki~PersistentIndexCorruption I remembered something I wanted to post a few years ago. I didn't bother because I did something pretty dumb by restoring a CDX, but not the corresponding DBF. So I figured, mea culpa and kept my mouth shut. ;)
>
>However, this is similar to a corrupted index. If an index has corrupted data, there should be a way to detect and treat the symptoms, and quite probably find a way to deal with the cause.
>
>Repro code:
>
>

>SET EXACT OFF
>CREATE TABLE CORRUPT FREE (FIELD1 C(10))
>INDEX ON FIELD1 TAG TAG1
>INSERT INTO CORRUPT (FIELD1) VALUES ("A")
>INSERT INTO CORRUPT (FIELD1) VALUES ("B")
>INSERT INTO CORRUPT (FIELD1) VALUES ("C")
>INSERT INTO CORRUPT (FIELD1) VALUES ("D")
>LOCATE FOR FIELD1 = "C"
>?"SHOULD BE .T. AND IS ",IIF(FOUND(),".T.",".F.")
>USE IN CORRUPT
>COPY FILE CORRUPT.CDX TO BACKUP.CDX
>USE CORRUPT
>REPLACE RECORD 3 FIELD1 WITH "E"
>USE IN CORRUPT
>COPY FILE BACKUP.CDX TO CORRUPT.CDX
>USE CORRUPT
>LOCATE FOR FIELD1="C"
>?"SHOULD BE .F. AND IS ",IIF(FOUND(),".T.",".F.")
>*Good, but if Rushmore uses the index(es) and the table
>*to determine which records to return, should it not give an error
>*when it sees the index has a record, but the table does not?
>SET ORDER TO TAG TAG1
>SEEK "C"
>?"SHOULD BE .F. AND IS ",IIF(FOUND(),".T.",".F.")
>*Shows .T., shouldn't it give an error?
>
>LOCAL lcSeekValue
>lcSeekValue = PADR("C",LENC(FIELD1))
>IF SEEK(m.lcSeekValue) AND EVALUATE(KEY())#m.lcSeekValue
>  WAIT WINDOW "INDEX CORRUPTED!" NOWAIT
>ENDIF
>

>
>I think there should be an error generated that we can either ignore (like VFP is now) or initiate a repair process. It is unreasonable to run a scan to check all indexes all the time, but checking the index against the data after every seek wouldn't slow things down too much, would it?
>
>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?

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.

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?

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?