Assume you have a table with one column of type INT which is the primary key. When you insert say 10000 rows in DESC order and then do a select * from that table with no order by clause, it returns the data in order from 1 to 10000.

Do the same thing, but on on a temporary/variable table and it’s out of order.

With smaller datasets, it works just fine on the temp/variable tables.

This is on SQL2000 SP4. I tested the same code in 2005 and the ordering is correct in both instances.

Does anyone know why I would get a different sort order in this instance?

Take the same logic and you can see why the OVER clause in SQL 2005 has the ability to have an ORDER BY.

In the most cases, the query resultset that don’t include ORDER BY clause and the table is clustered indexed returns the expected sequence that index are created (ASC or DESC), but there are some cases that doesn’t occur. I have experiment a lot of cases like that. SQL Server returns the resultset more efficiently and speedily, except when forced by a hint or other customizations (at least according query optimizer). This is the general rules.
About clustered index, they don’t physically reorders the data pages, they just do this in logical level reordering the sequence of b-tree pointers in the leaf nodes.
About the ORDER BY clause in views, there are a huge discussion between MCPs and MVPs to decide if this is a BUG or not. The facts are: This “problem” is caused by the SQL 2005 query optimizer, which ignores the TOP (100) PERCENT clause when returning the resultset. However, any other value of the TOP clause will work. Of course sorted views are inefficient and you should do the ORDER BY clause in the query that calls the view. Microsoft said that was a misconception about the ORDER BY clause in views and subqueries. In these cases, the ORDER BY and TOP clauses are not for ordering but only for select the rows that must be returned. In the early versions of SQL, the query optimizer is less efficiently as SQL 2005. But if this is right, why a TOP clause with a different value works fine? Even you test using a value greater than the number of rows in your table the results are ordered. Microsoft publishes a temporary hotfix for this supposed “bug” in http://support.microsoft.com/kb/926292 but this requires the compatible level 80.

Reference to the above statement i disagree with Pinal Dave and i think more attention is needed ,what i say, if you don’t include order by clause and your table is clustered indexed on one or more columns although you add disorder records, SQL will display them in sequence because we have got a clustered index on column/aolumns. Moreover, Adding a clustered index to the table physically reorders the data pages, putting them in physical order based on the indexed column/columns.

You didnt ask for an order, so you wont get one. The data in a relational DB is by definition not ordered. You want ordered data, then ASK for it ;)

You can even go 1 step futher..

Create view foobar as
select top 100 percent * from foo order by bar

select * from foobar

The above statement will not be a sorted resultset from foo. You did not ASK for an order, so the queryplan can actually drop the order request from the view. Even if this DID work on some older Versions of SQL Server, it is not an expected result.

You didnt ask for an order in your final querry, that means there is no need to order the result before returning it to you…