>>>Did you make sure that the collation on the tag is machine? I've seen weird things happen when it's anything else, and the index expression becomes a value conformant to current codepage's rules, not necessarily the same value that was calculated. Should not happen on character fields, but for any other kind of field, there's a possibility.
>>
>>Just to be curious.Could this happen for a table freshly created? I have machine as default, so it never happened to me.
>
>Yes it can. It's not something that happens over time, as a result of some bug, it's that when a value is written into a field, it conforms to the character translation table as per its collation sequence, so if e.g. your numeric index has a byte corresponding to é, it will be translated to a value such that it comes between e and f. Most of the time this doesn't matter, but when you hit such a value it's possible that a seek() returns not just a „not found“ but „not in index“, probably because seek() or other record-accessing functions respect the current set("collate"), not the one used when the index was created. Believe me, this was one of the hardest to catch, and it still found a way to bite me unexpectedly.
>
>Now if you don't use any collations... where do ö, ü and ä appear in your lists? In their proper places or...?

Al, Lutz, Dargan, Tamar -

Thank you all for your thoughts; this group of FoxPro developers is AWESOME!

All interesting thoughts, and indeed it appears to me that any activity that causes the index to be "refreshed" (REINDEX, recreating the index, etc.) seems to "solve" the problem.

I did look for NULLs or other non-printable characters in the data, but other than CR/LFs nothing popped.

Dragan - Very interesting thought re: collate sequence. I need to wrap this up this morning but will do one more test run as is to test out that theory.

Thanks all!