We are upgrading the Sql Server 2005 to 2008 and during the regression testing we found there is a mismatch with order of the record selected.
We have a SP say USP_getData, which creates local temp table to hold the records selected from multiple queries and selects the rows from that table at the end. There are no indexes on the temp table. hence the order of the data selected should be the order of the data.
The temp table has around 200 records. table has a identity column to record the order the rows are inserted in to it.
when I check the page id details for the row, from row 8, it goes to different page and after 90 records it uses the old page.
Below given is the Physical RID ( FileId:PageId:Slot) and the identify column.
(Physical RId) Identity
Another thing observed is, when perm tables are used instead of local temp table, the PageId and Identity are in order.
For local temp tables, selection of page id depends on space availability in the temp db. but I executed the same SP in different sessions and many times and it is still the case.
Would appreciate if you could advise on this .
- Перемещено Tom PhillipsModerator 8 июня 2012 г. 17:34 TSQL question (From:SQL Server Database Engine)
As the others have stated a table does not have an order. The query plan is different betweent the versions of SQL Server which is why it worked on the prior version (by coincidence). You have to add a order by clause to your query to ensure the data is returned in a consistent order.
As others have mentioned, there is no guarantee that rows will be returned in the same order for the same query without an ORDER BY clause. Demonstrated here -
Please mark this reply as the answer or vote as helpful, as appropriate, to make it useful for other readers.
Aalam | Blog (http://aalamrangi.wordpress.com)
There's a sliver of a chance the link in the first post of this thread might help: http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/23561fd3-ee35-45f2-9821-ec94748986b1. In other words, it may not be the temp table causing your problem, it may be that it's populated by an ordered view, which might by addressable by the hotfix.
It's a long shot, but worth investigating. However, it's still just not a good idea to depend on assumed behaviors like this. If whoever wrote this in the first place had used order by like they should have, you wouldn't be having this issue now!