>Found it.
>This was a problem with the COLLATE sequence.
>I had set it to "GENERAL" to provide case insensitivity for some queries.
>
>Now that I know I see some good discussion about this here.
>Also, this article spelled it out for me.
>
>http://fox.wikis.com/wc.dll?Wiki~UnderstandingRushmore~VFP

Between FPD/FPW 2.6 and VFP7 it was pretty much unimportant whether the collating sequence matched the codepage of the table, which has at times led to incorrect results in some cases. It was quite easy to have a tag on an integer key with a collating sequence which would translate some pairs of bytes into other pairs of bytes, and then Seek() wouldn't be able to find some keys, the numbers would appear out of sequence etc. There were other nasty things which could happen.

IIRC, it was VFP8 where the limitation was introduced, i.e. you can't apply any collate sequence to any table, they now have to match (ie. can't have a, say, Asian table and SweFin collation). The other limitation is that, starting with VFP9, it won't optimize if indexes with multiple collate sequences are used in the same query.