I believe that the second clause in the ORDER BY
is simply ignored in this particular case. After all if you do this:
DECLARE @t TABLE(i INT PRIMARY KEY, x UNIQUEIDENTIFIER);
INSERT @t VALUES(1,NEWID()),(2,NEWID()),(3,NEWID()),(4,NEWID());
SELECT i, x FROM @t ORDER BY i, x;
x
is not considered in the ORDER BY
, and why should it be? The first entity in the ORDER BY
clause already dictates the order, and the second clause can't change it. Since you're grouping by RecordID
, SQL Server is smart enough to realize that the first element in the ORDER BY
is unique, so it doesn't need to consider the second. I can't prove that, and I can make it fail when the second element is actually much more clear to SQL Server by using a constant, e.g.:
ORDER BY RecordID, CONVERT(1/0);
But when the output of the column is not easily known to SQL Server, and it can't do anything useful with the output anyway, it does the right thing (IMHO) and discards the expression without fully evaluating it and causing the runtime error. You can also make the error return if you don't first order by a column that is guaranteed to be unique:
ORDER BY CAST(CAST(SUM(Pts) AS decimal) / SUM(PtsOf) * 100 AS decimal(18, 0));