>Hi Mike,
>
>Are you insinuating that I did not read the help file? :-) I did, under SET COLLATE but did not see anything. It actually dawned on me 1/2 an hour after posting this to try that (isn't that usually the case - as an old guy used to say "thoughts disentangle themselves when they flow over the lips or through the finger tips".
>
>Regarding the UPPER() on the vars, I would have thought that this only fired once at the start of the command firing - not on every row. Just trying to avoid a couple extra lines.
>
>As you can probably tell, this discussion was also picked up over on Foxite. I had hoped that Steve Black might jump in as he used to be at least the guru on accented characters etc. I used his INTL app years ago to INTLize a hockey app. Everything seemed to work there - maybe I had better go over and open up that 2.6 code...

The trouble with 2.6 (to about 7.0... umm, sounds like the old "25 or 6 to 4" song now, doesn't it? :) was that you had the collating sequence under your control. Meaning that VFP didn't check it much, and if you didn't know exactly what you were doing, you could get technicolor stool.

So, back to your original (is it?) problem - first, under collate="GENERAL", "a"="A" is .t., so you can lose the upper() altogether. It wouldn't do you any good anyway, because you can't expect a query on upper() to be optimizable if you have a tag on the bare field, not upper(field). Which would be unnecessary under General collation, General is case blind (I'd almost say he's generally blind - just create a cursor with a c(1) field, and have 256 records with chr(recno()) in this field, index it General and be amazed with results ;).

So try it again, without upper() anywhere, and Set Collate to "General" before you run the query, and restore it on exit. If you have one of those handy cSet classes for that, use it.

Although I'm not quite sure the query will be optimizable now, at least it should be faster and giving some results.