>>>>It's here: using '==' is much slower than '='.
>>>
>>>Depending on the ANSI setting, no?
>>
>>You know, the only way to have definite opinion about optimization is to test it. I just tested again and see that '=' is always better than "==", and Set ANSI OFF is always better than ON (in any combination).
>>I will appreciate any thoughts about it.
>
>From the help on ANSI :
>
>SET ANSI determines whether the shorter of two strings is padded with blanks when a SQL string comparison is made. SET ANSI has no effect on the == operator; when you use the == operator, the shorter string is always padded with blanks for the comparison.
>
>'Tommy' = 'Tom'
>The result is false (.F.) if SET ANSI is ON.
>
>'Tommy' = 'Tom'
>The result is true (.T.) when SET ANSI is OFF.
>
>'Tommy' == 'Tom' returns false.
>
>So I guess it's better to set ANSI to ON to have proper results
>with the '=' operator.
>
>Claude.

Thanks for all the help, I was able to fix the query we were testing by using SYS(3054,1) to assist in my optimization efforts.

After I got full optimization on this query I moved on to the others. When I encountered this one:

Sys(3054,1)

SELECT Test_category,sort_index,cost_of_analysis,department_cat,department_code;
FROM testlib WHERE testlib.test_code=UPPER(tmp_code) INTO CURSOR spec_cur

The system reported that optimization was only partial, but when I run this same query in the command window optimization is full.

Any ideas ?