>>>>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 ?
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only