I agree. Either you want a sort by a field (expression), or you won't. In the last case, the order is arbitrary. often, it's indeed the order of record entry, but the database engine has the freedom to reorganize the table, so the order of records isn't determined by anything.
Make everything as simple as possible, but not simpler! - A. Einstein
DB Problems? DB Explorer, BTrieve Re-engineering, DB Conversions & ETL? Conversion Tool
In theory (Relational Algebra), an entity (table) has no order. Tuples (rows) exist inside the entity, but there isn't any "where" so there is no order.
In practice, a database engine has to store the stuff somehow. It gets an order as a result of storage. That order might be repeatable, it might not, but it is still there.
Applications that rely on that order are just accidents waiting to happen. It isn't a question of if they will break, that is a given. The only real question is when and how will they break.
I think that the original poster was looking for a way out of an ugly situation. They inherited a database without any temporal record, and were hoping to find a way to create one at least sort of equitably.
In MS-SQL, if there isn't a clustered index and a SELECT statement uses index 0, the rows will appear to be in the same order that they were entered into the table. If there is a clustered index, I don't think there is any way to recreate the order of entry unless there is some kind of temporal column like a data_entered or a sequential id (aka IDENTITY) column which you can use for the order.
Hans managed to shoot himself in the foot while demonstrating a technical point that I hadn't mentioned!
By using an identity column (which is temporal), Hans implicitly created just the kind of opportunity for ordering that chnoeh seems to be looking for! If the original table had had an identity column, then chneoh could simply order by that column to get the rows in the order that they were inserted (unless somebody used SET IDENTITY_INSERT to mess up even that).
Hans makes a good point though. If the table isn't a strict log (rows added and possibly updated but never deleted), even the "default order" of the heap goes bad.
The short answer is that there isn't any foolproof way that I know to retrieve the rows in the order that they were inserted into the table, unless you have a column that will allow you to determine when a row was entered.
"Shoot himself in foot" means I make mistake? Where? :-)
I used IDENTITY because is obvious what order rows were entered, and yes this does make obvious one solution to OP's issue, but now is too late. I prefer datetime column with GETDATE() default as in last Brett Kaiser post, but either identity (with SET IDENTITY INSERT) or datetime (with update) can be ruined. I prefer datetime because is more explicitly temporal then identity and does not give arbitrary result if a set is inserted in one operation.
Never rely on any implicit order, not even that of clustered index. If query optimizer chooses parallel plan then result set without ORDER BY clause often has not order even of clustered index. This is good because it delineates between theoretical and physical. One should know about the physical of course, but not rely on physical artifacts when writing SQL.