>>In my experience I found that with the index on records past the point of corruption are no longer reachable with the SEEK on the indexed field, so seeking the largest indexed value usually fails.
>>
>>I've also observed that with the index on scrolling through a browse window while observing the values of the indexed field will reveal discontinuities, i.e., the values would look like this (using a made up example)
>>234
>>236
>>237
>>238
>>240
>>5764
>>241
>>243
>>...
>>and so on.
>>HTH
>>JLK
>
>Jerry,
>
>I never thought about it this way.
>
>Do you see any problem with the following approach? Perhaps I can do it in my free time.
>
>Write a generic program that issues SET DELETED OFF, and then scans through the table for each index (with SCAN ... ENDSCAN), comparing: 1) that eval(IndexExpression) for each record is >= eval(IndexExpression) for the previous one, and 2) that the total number of records thus processed = reccount()? Also, the program should stop after processing reccount() + 1 records - it seems to me that otherwise, a corrupted index might produce an "endless loop".
>
>Hilmar.

I do something similar. I have a method or prg that opens a table exclusively , sets a specific index on and then skips through the table checking that the next index value is always greater than the previous one until I reach EOF. If a value is regressive then the index is corrupt and I issue pack command. Pack rebuilds all indicies. I then test the next table. Otherwise, if no corruption on an index is found and I reach EOF, I set order to the next indexl, issue a LOCATE command and reloop (DO WHILE with SKIP- not SCAN) through the table testing the next index. With 23 multi-user apps working against over 200 tables I have had only two cases of corruption in four years.
JLK