Excuse me for asking a dumb question here but the OP says the TransactionID is the primary key with presumably a clustered index on it (my assumption).
In that case, without an ORDER BY shouldn't the rows be returned in the order established by the clustered INDEX?
Otherwise, how would a QU ever work?
That's a part of the bone of contention that some folks have with the Quirky Update. The QU depends on the use of the Clustered Index AND that it's used in an "ORDERED" fashion. That's the reason for all the rules such a MAXDOP 1 and referencing the lead column of the CI, etc. Paul White came up with a method (referenced at the beginning of the "latest" article) that uses a CTE with a RowNumber and a counter in the outer query that must match or it gives you an error. Oddly enough, the method seems to guarantee that if the QU is setup correctly to run to begin with, it'll never error.
As for relying on the CU for a "natural" sort of other things goes, it's not guaranteed especially if there's another unique index on the table. Other than some of the trickery in the rules of a QU, the only way to guarantee order in a SELECT is to use an ORDER BY. If SQL Server decides to use the CI in an "ORDERED" mode, it'll ignore the sort... it won't even include it in the execution plan.
is pronounced ree-bar and is a Modenism for R
First step towards the paradigm shift of writing Set Based code: Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs