First, and to be sure, I always appreciate anyone that steps up to the plate with an article, especially on such a topic.
I agree with Aaron. This is NOT a "Set-Based" solution because incremental rCTEs (recursive CTEs) are NOT "Set-Based". The bit of code that makes this rCTE "incremental" is the following code snippet from the "C1" CTE...
from #regs Regs
inner join C1 on Regs.Rn = C1.Rn + 1
In many cases, a properly written WHILE loop can beat an incremental rCTE while using a whole lot less resources in the form of logical reads.
I also don't actually know if this code does a good job at how it does the packing. That's not to say that it's doing a bad job but I look at this and can't say it's actually doing a good job, either. That will take a bit more scrutiny.
As a suggestion, the table output that you have in the article doesn't match the output from the code. It will provide less confusion to your readers if it does.
As a general observation (lots of other authors end up doing the same) and another suggestion, it doesn't instill a whole lot of faith in an author when they talk about having a created a set based solution and then they use a WHILE loop to build the test data.
Just to reiterate, though, thank you. I appreciate that you took the time to write and publish this article. I'll echo Aaron's statement that this IS an interesting approach and the article has gotten people's creative juices flowing.
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.
"Change is inevitable... change for the better is not".
"Dear Lord... I'm a DBA so please give me patience because, if you give me strength, I'm going to need bail money too!"
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)