Your observation regarding TOP being after order by is correct in cases where ORDER BY is present. I had a parenthetical caveat in there when I first drafted the comment that would have made the generalization more specific (“as the standard applies to these statements”), but I thought it too wordy.

It looks like you have seen my comments here:
http://blog.sqlauthority.com/2009/04/06/sql-server-logical-query-processing-phases-order-of-statement-execution/

My comments there address the specifc case of TOP and ORDER BY.

BTW, great site pinaldave!

On my final point, I think it’s unclear/weak. I’d like to add that the most clear reason as to why you can’t expect to get AB or BA, but might in fact get just A or just B, is that the construct @=@ +col is non-deterministic and therefore, for the same range of input values, is not guaranteed to produce the same result in every instance.

Very nice explanation. I do have some comments.

“The ORDER BY clause only pertains to the final results from an ANSI perspective (at least, for these queries). ”

TOP is after the ORDER BY. The help file (TOP) explains that.
SELECT…INTO ignores the ORDER BY (see ORDER BY).

SQL Server’s implementation of ORDER BY is arbitrary. I just don’t feel the ANSI standard is truly an answer.

Very informative and interesting note. I ran your example and got similar result. You are very correct and clear in your example.

I am sure blog readers will enjoy reading this particular comments of yours and learn something new.

Kind Regards,
Pinal

SELECT @Str0 = @Str0 + C1 FROM T1

into a table expression (i.e. VIEW, FUNCTION, FROM (SELECT)), you may get the results you want over and over until the one day where you call the view or function with the combination of syntax that triggers the unexpected behavoir.

When CAST is used with a datetime, it is non-deterministic, which would change the optimization path. In this case, the implicit CAST from nchar to varchar is deterministic. My only point being that your example would be treated differently by the optimizer, so it’s probably not a similar enough case. If you’re using @date = @date + datecol over a set of rows, I think you should consider some different construct.

If you want to see what’s going on here, I think you need to shift your point of view from an implementation-centric view to an ANSI point of view. ANSI does not guarantee processing order. Figure 2 is interesting, but it will be potentially misleading if you don’t understand the ANSI rule-set SQL Server operates under in most cases. Implementation thinking can certainly be useful at times when you really need that multi-million row query to finish before the backups fire off, but in this case, it’s counterproductive to understanding what is going on.

First off, your statements all return a single row, which were properly sorted according to your ORDER BY expression; which is to say that there was really no sorting to be done because only a single row is returned. So let’s forget about the ORDER BY. Forget that the execution plan shows 2 rows being sorted — that’s implementation specific. A different vendor’s product could have an optimizer smart enough to see that only a single row can ever be returned from this query and therefore, avoid the unnecessary sort altogether.

Secondly, you are not guaranteed that the string concatenation will occur in any particular order. The ORDER BY clause only pertains to the final results from an ANSI perspective (at least, for these queries). MS SQL Server is right in line with ANSI and will not guarantee you anything different. Don’t expect to get AB in every case.

Finally, SQL works using relational sets, so the construct varchar = varchar + varchar forms a relational set that is evaluated accordingly. I have seen this type of construct used many times and it works sometimes – until it doesn’t. This is why you get only B in one example where I suspect you wanted AB. After thinking about it a bit, I built this example which I hope is just different enough to show you the same mechanism is at work here:
DECLARE @sum INT
SELECT @sum = 0
SELECT @sum = @sum + num FROM (
SELECT 1 [num] UNION SELECT 2 [num]
) [a] ORDER BY (num * num)
SELECT @sum [Is it 3]

I tried to show two things here. The first is that the ORDER BY isn’t doing what you think it’s doing with respect to the order of concatenation in your query. The order here is nonsensical. The second thing I think the example shows is that 1+2 doesn’t equal 3 with this @ = @ + col construct in all cases. It’s a bad construct to use. Remove the ORDER BY and you get 3, leave it in and you get 2. Heck, someone else could get 1 in theory. There’s a case I see all the time where this is used, but I can’t quite recall it. I’ll post it if I think of it again.

And thanx for the link to Ward’s blog!