Why is SSMS inserting new rows at the top of a table not the bottom?

Question

Whenever I manually insert a row into a table in SQL Server Management Studio 2008 (the database is SQL Server 2005) my new row appears at the TOP of the list rather than the bottom. I'm using identity columns and this results in things like

id  row
42 first row
1 second row
2 third row

When rows are fetched and not explicitly ordered. This results in a different appearance when the rows are fetched for the web app and changes what a TOP 1 query returns.

I know I can order by them, but why is this happening? Most of my data is inserted through a web application, all inserts from this application result in a First In First Out ordering, e.g. latest insert is at the bottom, so the ids are all in a row. Is there some setting in the server or Management Studio that causes this improper ordering?

Answer 1

In the SQL world, order is not an inherent property of a set of data. Thus, you get no guarantees from your RDBMS that your data will come back in a certain order -- or even in a consistent order -- unless you query your data with an ORDER BY clause.

From Craig Freedman:

Combining TOP with ORDER BY adds determinism to the set of rows returned. Without the ORDER BY, the set of rows returned depends on the query plan and may even vary from execution to execution.

Always use ORDER BY if you expect a well-defined and consistent order in your result set. Never rely on how your database may store the rows on disk (e.g. via a clustered index) to guarantee a certain ordering of data in your queries.

Answer 2

Just to augment the other answers: a table is, by definition, an unordered set of rows. If you don't specify an ORDER BY clause, SQL Server is free to return the rows in whatever order it deems most efficient. This will often just happen to coincide with the order of insert, since most tables have a clustered index on identity, datetime or other monotonically increasing columns, but you should treat it exactly as that: a coincidence. It can change with new data, a statistics update, a trace flag, changes to maxdop, query hints, changes to the join or where clauses in the query, changes to the optimizer due to a service pack/cumulative update/hotfix/upgrade, moving the database to a different server, etc. etc.

In other words, and I know you already know the answer, but it can't be stated enough:

If you want to rely on the order of a query, ALWAYS add ORDER BY.

Answer 3

It's because the table is a heap table (most likely) and is not indexed. Make the ID column a PRIMARY KEY as well as IDENTITY. SQL Server physically stores the data based on the indexes - for example, if id were a clustered index (such as a primary key) the data would be physically stored in the order of the ids and would be returned that way (usually but not always) in a query even without an ORDER BY clause.

Anyway, the ordering of the rows is not important to the database at all. Consequently, having an application depend on the order of the rows in the database (as well as depending on columns being in a certain order) is not a good practice. The application needs to work with whatever keys there are in the database to identify rows.