Wondering how much space you could save by compression all those disk eating tables?
While writing this Stored Procedure I wanted to properly unit test in SSDT, I faced this annoying little issue:
- My Stored Procedure, let’s call it
MainProcedure, had to call another Stored Procedure, let’s call itSubProcedure. - The
SubProcedurehad some dodgy and time-consuming side-effects that I didn’t want to see happen during a Unit Test. Plus, theSubProcedurewas not the one being tested anyway. - Considering this, I wanted to isolate the code in
MainProcedureusing a Dependency Injection / Inversion Of Control pattern somehow. - Unfortunately, this is not supported out-of-the-box in SSDT, plus to be fair, IoC is not something the T-SQL language lends itself to easily at all: You can’t just pass a type-safe reference to a Stored Procedure in your parameters.
After some head scratching and searching the web for what wasn’t there, I arrived at a couple of options:
How? As easy as running the code below.
The SQL Server Data Collector is like a Swiss army knife sometimes. So much stuff you can do with it. The challenge is to know how. So how do we use it to monitor SSRS report execution times and know your SLAs are up and about?
I really need to come up with shorter titles. But I like long Waltzes, what can I do.
While working on a mini (and I emphasize the mini) multi-scenario (also emphasize the multi) performance testing structure (so a multi-mini kind of) using the SQL Server Data Collector (SSDC), I found myself wanting to extend the Management Data Warehouse with new functionality, but not really wanting to create new stuff in the MDW itself. The thing is, the MDW itself is not your code. It can be changed by Microsoft at any time (even though they haven’t touched it in years), so it’s really out of your project’s control. However, to make the MDW dance to a new Tango, you do have to get some T-SQL code of your own in there, playing new tunes for it to enjoy.