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 ENDIFI 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?