• CREATE VIEW (Transact-SQL) SQL Server 2005 states the following: "The ORDER BY clause is used only to determine the rows that are returned by the TOP clause in the view definition. The ORDER BY clause does not guarantee ordered results when the view is queried, unless ORDER BY is also specified in the query itself." Most folks assume that the rules which apply to views apply to derived tables also.

    SELECT TOP (100 PERCENT) is optimised out as Dave B stated, it's meaningless. I think you can still cheat with SELECT TOP 2147483647 or some other number safely bigger than the anticipated rowcount of the result set.

    It looks like another part of the query relies on the records being a specific order so it can do some differential calcs.

    Even if the ORDER BY worked, it would be unlikely to do anything except introduce an unnecessary sort; what would happen to the results from this derived table if the next join operator was anything other than a merge join without a presort? For the query to work as designed, you'd need merge joins (without presorts) all the way between this output and "another part of the query".

    So, if the query results are correct it's certainly not by design - which means it works by accident.


    [font="Arial"]Low-hanging fruit picker and defender of the moggies[/font]

    For better assistance in answering your questions, please read this[/url].


    Understanding and using APPLY, (I)[/url] and (II)[/url] Paul White[/url]

    Hidden RBAR: Triangular Joins[/url] / The "Numbers" or "Tally" Table: What it is and how it replaces a loop[/url] Jeff Moden[/url]