Kendra's example was purely to show unintended consequences of making seemingly harmless changes to databases. Despite appearances, there is absolutely nothing that she's done that demonstrates that having multiple temp files affects the order in which data is imported. She did, however, do a great job demonstrating an accident just waiting to happen.
To wit, the REAL problem with the code (which she hasn't explained because that wasn't the objective of the article) is the addition of an IDENTITY column after the table is populated. The order of the IDENTITY values that will appear in such an "after the fact" manner is absolutely NOT guaranteed to be in what people think is the correct order according to the data present.
And, YES!!! I have the proof in the form of code! I'm in the process of writing it up.
Another set of unintended lessons that I believe you need to learn from her fine post is to expect the unexpected, knowing more about T-SQL before you decide "good enough" really is, and taking the time to make your code as bullet proof as possible.
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