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?