Heh... no pun intended but I hate today's damned keyboards. They provide no tactical feedback as to if the key-press was deep enough to register.
The only way to make this non-RBAR would be to rewrite the functionality provided by sp_estimate_data_compression_savings, which is loaded with RBAR to begin with. I don't know why Microsoft continues to write single object stored procedures other than it's an easy thing to do and control loops (as opposed to row loops) aren't that expensive and so they leave such things up to the users.
I rewrote sp_spaceused for my own purposes when I needed single result set returns for many objects (worked really well for seeing the meta-data "guts" of partitioned tables all at once, as well). You can also see the code for sp_estimate_data_compression_savings using sp_helptext, so someone could rewrite it to be less RBAR in nature but that probably won't be me because I don't actually have a need to do so and the number of times that someone might actually use it are pretty small.
There are other scripts similar to the one posted out there that will return compression estimates even if compression is already in play. That's kind of important if you're into this kind of thing because it just may be that the original type of compression isn't the best and it would be nice to see if compressing or even decompressing might be a better thing to do. They also don't depend on data that might not be there after a service bounce.
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.
If you think its expensive to hire a professional to do the job, wait until you hire an amateur. -- Red Adair
When you put the right degree of spin on it, the number 318
is also a glyph that describes the nature of a DBAs job. Helpful Links:
How to post code problemsHow to post performance problemsForum FAQs