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

In regard to this particular thread it means that Client_code (primary/foreign key) should be of equally trimmed length for all cases:
"001","002","003",etc.
But not like "01","011","0115",etc.