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