[snip] I understand that is the behavior of the assignment operator. That's why I used it. ;-) I expected the results to be 19 and 6 not 19 and 20. This is just another example of the serialization of evaluation that occurs while processing a single row of data. I have the opinion that while processing that row, the variable @testvalue should keep its original value and only be updated when moving to the next row(statement). [/snip]
This has nothing to do with serialization, you have reassigned the variable value, and like any other programming language the new value is valid until it is reset by something else, so any subsequent operation will use that value. I believ that what you would like here is a CONSTANT [snip] If evaluation is serialized in a SELECT statement based on the order in which they are listed, then why aren't they evaluated in that order during the processing of a SET clause? Why does the query engine seem to revert to processing changes in "table column order" and not maintain the "statement sequence order" as specified by the user? That could imply that I need to change the design of my tables so that my update statements will execute in the correct order. If only the changes had happened in the sequence specified in Kai's original SET statement... (sigh) 8-D [/snip] It is because you are defining the order of the update in the UPDATE statement itself; UPDATE t2, t1, t0 You have now specified the order of the update regardless of the actual updates that occur in the SET statements. SETs do not define order, even in single table/multiple column updates. If I do SELECT t2.foo, t1.bar my results come out in the order specified in the SELECT statement, not the order in the FROM or subsequent condition statements...so the behavior really is no different between SELECT and UPDATE. -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
