>As it's not a seek i think index corruption isn't in case. I would think at a case sensitive or a difference of lenght (alltrim(upper())) or as said before a filter or a relation still active...

I doubt it's the case here. From what I remember about the UT Nav, Michel uses integer keys.

Could it be something changed a value of one of the fields later, so it became a duplicate of another record? One thing to check about these duplicates is if there's a missing value in the sequence of one for some other value of the other field (i.e. NOMEMBER value which is duplicate could be a missing value for some other value of NOCLIENT; it was OK while a pair to this other value).

Of course, if this is the case, it's slightly worse than index corruption.

BTW, collating sequence (any one but Machine) may influence Rushmore not to find certain values, even when using integer keys. I remember that under one of the 1250 sequences, seek(15) on an integer key (actually, on BinToC(intkey)) couldn't find the record which was obviously there.