Hi Mike,

>Hi Jim
>
>SNIP
>
>>Technically, Mike (Y that is), you are relying on an undocumented feature in your assertion that the UPPER() is not necessary.
>>I'd argue that inclusion of the UPPER() function is very cheap "insurance" against future malfunction if the situation were to change, whether deliberately or accidentally.
>
>I use mdot as cheap insurance against a problem that could crop up innocently and without warning. I don't see this as the same thing.
>
>I don't buy insurance on my house in case the moon should fall on it. ;) MS can't change it while code is running and they would not change it without it getting caught in a beta and having to put it back. I think it extremely unlikely that MS is going to change SET("CLASSLIB") or any other SETs to return mixed/lower case values. If they did change that, they'd document it. Just looking in the help for SET(), many of them are clearly uppercase already (ON or OFF).

Ahhh, I see. You mean like the .CDX file doubling in size with VFP7 SP1? Or the many other things that get reported as 'worked in last version but doesn't with the lastest?

>
>In addition, it is often faster to
>

lcVariable = UPPER(m.lcVariable)
>SET FILTER TO UPPER(field) = m.lcVariable<PRE>
>than to <pre>SET FILTER TO UPPER(field) = UPPER(variable)

>
>It may be insurance, but it isn't *necessary*.

Insurance isn't "necessary" but it is often smart, especially when, in a case like this, it is sooooo cheap!
I call it "defensive coding" and while one never knows if it pays off, it surely can't hurt.

>
>BTW. How come you're not requesting they document the case of the returned value?

First, how do you know that I didn't? < s > But in fact I haven't and won't, because over a dozen submissions to the standard documentation link have resulted in ZERO changes so far.

cheers