>>>>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.