A test like this comes to mind:

set order to
lcKey=key(1)
lcTag=tag(1)
scan
   lcValue=eval(lcKey)
   if not indexseek(lcValue, .f., alias(), lcTag)
      wait window "scream"
   endif
endscan

This should be reworked for a double loop (for all the keys), and it wouldn't give a thorough test, because for the keys with repeated values, any seek finds the first record with that value, doesn't guarantee to find them all. Since there's no way that I know of to retrieve the key value from the cdx and to be sure it's not coming from the dbf... can't think of a better test.

So yeah, I think Fox should yell at this. Imagine code like

?HowIsTable("mytable")
Needs reindexing.

>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:
[scissors icon here]
>
>
>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?