Hi Fabio,

Your post only proves that VFP UPDATE-SQL isn't compliant with the ANSI SQL standard. It doesn't make it a bug. BTW, I agree with you that VFP SQL command shoul be comliant with ANSI SQL as much as possible so it would be easier to work with different backends.

>I can accept, and it is a good thing, that the low level record based command
>

>REPLACE fieldName1 WITH exp1, fieldName2 WITH exp2
>

>is executed with a left to right evaluation:
>

>eval exp1
>put this into fieldName1
>eval exp2 && if this use fieldName1, it use the new replaced value
>put this into fieldName2
>

>
>The UPDATE SQL is a set based command
>

>UPDATE tableName SET fieldName1 = exp1, fieldName2 = exp2
>

>and i aspected that the order of the setting list not influence the result.
>
>Then the implementation it have to compute update values ( like a VFP expression ),
>and after set these values within the relative fields,
>like this:
>

>eval exp1
>eval exp2 && if this use fieldName1, it use the old value
>put exp1Value into fieldName1
>put exp2Value into fieldName2
>

>
>A simple example:
>I want swap two fields into a table:
>( Is impossible do this simple task into VFP8 without additional operations )
>

>CLEAR
>CREATE CURSOR myCursor (f1 I , f2 I )
>INSERT INTO myCursor VALUES (1,-1)
>
>UPDATE myCursor SET f1=f2 , f1=f1
>? f1,f2, "exspected -1,1"
>

>
>without
>

>or
>- add a dummy field
>or, only in VFP9
>- do a join with a copy of the same table via a primary key
>

>
>Another little problem is this:
>if you traslate a VFP UPDATE into MS SQL or others backend
>the update set work in "independently from the set order".
>
>Of course, exists situations where this bad mode can to be useful,
>but every bad or bug behaviour has always some situations nearly where it can be useful.
>
>Why i write this now ?
>
>Because the new VFP9 improvements
>they supplied an optimal moment of change,
>eventually tying this to SET ENGINEBEHAVIOR 90
>