>>>>>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.
>
>It's better to have normalized primary-foreign key definitions which will exclude necessity to use SET ANSI ON.
Could you tell more about "normalized definitions".
thanks
Claude
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