Stored Procedures with SSRS? Hmm… not so much

Little Bobby Tables' mother says you should always sanitise your data input. Except that I think she's wrong. The SQL Injection aspect is for another post, where I'll show you why I think SQL Injection is the same kind of attack as many other attacks, such as the old buffer overflow, but here I want to have a bit of a whinge about the way that some people sanitise data input, and even have a whinge about people who insist on using stored procedures for SSRS reports.

Let me say that again, in case you missed it the first time:

I want to have a whinge about people who insist on using stored procedures for SSRS reports.

Let's look at the data input sanitisation aspect – except that I'm going to call it 'parameter validation'. I'm talking about code that looks like this:

Notice that the code checks that a date has been entered. Seriously??!! This must only be to check for NULL values being passed in, because anything else would have to be a valid datetime to avoid an error.

The other check is maybe fair enough, but I still don't like it.

The two problems I have with this stored procedure are the result sets and the small fact that the stored procedure even exists in the first place. But let's consider the first one of these problems for starters. I'll get to the second one in a moment.

If you read Jes Borland (@grrl_geek)'s recent post about returning multiple result sets in Reporting Services, you'll be aware that Reporting Services doesn't support multiple results sets from a single query. And when it says 'single query', it includes 'stored procedure call'. It'll only handle the first result set that comes back. But that's okay – we have RETURN statements, so our stored procedure will only ever return a single result set.  Sometimes that result set might contain a single field called ErrorMessage, but it's still only one result set.

Except that it's not okay, because Reporting Services needs to know what fields to expect. Your report needs to hook into your fields, so SSRS needs to have a way to get that information. For stored procs, it uses an option called FMTONLY.

When Reporting Services tries to figure out what fields are going to be returned by a query (or stored procedure call), it doesn't want to have to run the whole thing. That could take ages. (Maybe it's seen some of the stored procedures I've had to deal with over the years!)

So it turns on FMTONLY before it makes the call (and turns it off again afterwards). FMTONLY is designed to be able to figure out the shape of the output, without actually running the contents. It's very useful, you might think.

Without the FMTONLY lines, this stored procedure returns a result set that has three columns and fourteen rows. But with FMTONLY turned on, those rows don't come back.

But what I do get back hurts Reporting Services.


It doesn't run the stored procedure at all. It just looks for anything that could be returned and pushes out a result set in that shape. Despite the fact that I've made sure that the logic will only ever return a single result set, the FMTONLY option kills me by returning three of them.

It would have been much better to push these checks down into the query itself.

Now if we run it with FMTONLY turned on, we get the single result set back. But let's consider the execution plan when we pass in an invalid date.

First let's look at one that returns data. I've got a semi-useful index in place on OrderDate, which includes the SalesPersonID and TotalDue fields. It does the job, despite a hefty Sort operation.


…compared to one that uses a future date:


You might notice that the estimated costs are similar – the Index Seek is still 28%, the Sort is still 71%. But the size of that arrow coming out of the Index Seek is a whole bunch smaller.

The coolest thing here is what's going on with that Index Seek. Let's look at some of the properties of it.


Glance down it with me… Estimated CPU cost of 0.0005728, 387 estimated rows, estimated subtree cost of 0.0044385, ForceSeek false, Number of Executions 0.

That's right – it doesn't run. So much for reading plans right-to-left…

The key is the Filter on the left of it. It has a Startup Expression Predicate in it, which means that it doesn't call anything further down the plan (to the right) if the predicate evaluates to false.


Using this method, we can make sure that our stored procedure contains a single query, and therefore avoid any problems with multiple result sets. If we wanted, we could always use UNION ALL to make sure that we can return an appropriate error message.

But still I don't like it, because it's now a stored procedure with a single query. And I don't like stored procedures that should be functions.

That's right – I think this should be a function, and SSRS should call the function. And I apologise to those of you who are now planning a bonfire for me. Guy Fawkes' night has already passed this year, so I think you miss out. (And I'm not going to remind you about when the PASS Summit is in 2012.)

We've had to lose the ORDER BY – but that's fine, as that's a client thing anyway. We can have our reports leverage this stored query still, but we're recognising that it's a query, not a procedure. A procedure is designed to DO stuff, not just return data. We even get entries in sys.columns that confirm what the shape of the result set actually is, which makes sense, because a table-valued function is the right mechanism to return data.

And we get so much more flexibility with this.

If you haven't seen the simplification stuff that I've preached on before, jump over to and watch the video of when I broke a microphone and nearly fell off the stage in Wales. You'll see the impact of being able to have a simplifiable query. You can also read the procedural functions post I wrote recently, if you didn't follow the link from a few paragraphs ago.

So if we want the list of SalesPeople that made any kind of sales in a given month, we can do something like:

This doesn't need to look up the TotalDue field, which makes a simpler plan.

This one can avoid having to do the work on the rows that don't have a SalesPersonID value, pushing the predicate into the Index Seek rather than filtering the results that come back to the report.

If we had joins involved, we might see some of those being simplified out. We also get the ability to include query hints in individual reports. We shift from having a single-use stored procedure to having a reusable stored query – and isn't that one of the main points of modularisation?

Stored procedures in Reporting Services are just a bit limited for my liking. They're useful in plenty of ways, but if you insist on using stored procedures all the time rather that queries that use functions – that's rubbish.


SQLRally Nordic gets underway

PASS is becoming more international, which is great.

The SQL Community has always been international – it's not as if data is only generated in North America. And while it's easy for organisations to have a North American focus, PASS is taking steps to become international. Regular readers will be aware that I'm one of three advisors to the PASS Board of Directors, with a focus on developing PASS as a more global organisation.

With this in mind, it's great that today is Day 1 of SQLRally Nordic, being hosted in in Sweden – not only a non-American country, but one that doesn't have English as its major language.

The event has been hosted by the amazing Johan Åhlén and Raoul Illyés, two guys who I met earlier this year, but the thing that amazes me is the incredible support that this event has from the SQL Community.

It's been sold out for a long time, and when you see the list of speakers, it's not surprising.

Some of the industry's biggest names from Microsoft have turned up, including Mark Souza (who is also a PASS Director), Thomas Kejser and Tobias Thernström. Business Intelligence experts such as Jen Stirrup, Chris Webb, Peter Myers, Marco Russo and Alberto Ferrari are there, as are some of the most awarded SQL MVPs such as Itzik Ben-Gan, Aaron Bertrand and Kevin Kline. The sponsor list is also brilliant, with names such as HP, FusionIO, SQL Sentry, Quest and SolidQ complimented by Swedish companies like Cornerstone, Informator, B3IT and Addskills.

As someone who is interested in PASS becoming global, I'm really excited to see this event happening, and I hope it's a launch-pad into many other international events hosted by the SQL community.

If you have the opportunity, thank Johan and Raoul for putting this event on, and the speakers and sponsors for helping support it. The noise from Twitter is that everything is going fantastically well, and everyone involved should be thoroughly congratulated!


When is a SQL function not a function?

Should SQL Server even have functions? (Oh yeah – this is a T-SQL Tuesday post, hosted this month by Brad Schulz) TSQL2sDay150x150

Functions serve an important part of programming, in almost any language. A function is a piece of code that is designed to return something, as opposed to a piece of code which isn't designed to return anything (which is known as a procedure). SQL Server is no different. You can call stored procedures, even from within other stored procedures, and you can call functions and use these in other queries. Stored procedures might query something, and therefore 'return data', but a function in SQL is considered to have the type of the thing returned, and can be used accordingly in queries. Consider the internal GETDATE() function.

There's no logical difference between the field that is being returned by the function and the field that's being returned by the table column. Both are the datetime field – if you didn't have inside knowledge, you wouldn't necessarily be able to tell which was which. And so as developers, we find ourselves wanting to create functions that return all kinds of things – functions which look up values based on codes, functions which do string manipulation, and so on.

But it's rubbish.

Ok, it's not all rubbish, but it mostly is. And this isn't even considering the SARGability impact. It's far more significant than that. (When I say the SARGability aspect, I mean "because you're unlikely to have an index on the result of some function that's applied to a column, so try to invert the function and query the column in an unchanged manner")

I'm going to consider the three main types of user-defined functions in SQL Server:

  • Scalar
  • Inline Table-Valued
  • Multi-statement Table-Valued

I could also look at user-defined CLR functions, including aggregate functions, but not today. I figure that most people don't tend to get around to doing CLR functions, and I'm going to focus on the T-SQL-based user-defined functions.

Most people split these types of function up into two types. So do I. Except that most people pick them based on 'scalar or table-valued'. I'd rather go with 'inline or not'.

If it's not inline, it's rubbish. It really is.

Let's start by considering the two kinds of table-valued function, and compare them.

These functions are going to return the sales for a particular salesperson in a particular year, from the AdventureWorks database.

You'll notice that I'm being nice and responsible with the use of the DATEADD function, so that I have SARGability on the OrderDate filter.

Regular readers will be hoping I'll show what's going on in the execution plans here. Here I've run two SELECT * queries with the "Show Actual Execution Plan" option turned on.


Notice that the 'Query cost' of the multi-statement version is just 2% of the 'Batch cost'. But also notice there's trickery going on. And it's nothing to do with that extra index that I have on the OrderDate column.


Look at it – clearly, the first plan is showing us what's going on inside the function, but the second one isn't. The second one is blindly running the function, and then scanning the results. There's a Sequence operator which is calling the TVF operator, and then calling a Table Scan to get the results of that function for the SELECT operator. But surely it still has to do all the work that the first one is doing…

To see what's actually going on, let's look at the Estimated plan.


Now, we see the same plans (almost) that we saw in the Actuals, but we have an extra one – the one that was used for the TVF. Here's where we see the inner workings of it. You'll probably recognise the right-hand side of the TVF's plan as looking very similar to the first plan – but it's now being called by a stack of other operators, including an INSERT statement to be able to populate the table variable that the multi-statement TVF requires.

And the cost of the TVF is 57% of the batch!

But it gets worse.

Let's consider what happens if we don't need all the columns. We'll leave out the EmployeeLogin column.


Here, we see that the inline function call has been simplified down. It doesn't need the Employee table. The join is redundant and has been eliminated from the plan, making it even cheaper. But the multi-statement plan runs the whole thing as before, only removing the extra column when the Table Scan is performed.

A multi-statement function is a lot more powerful than an inline one. An inline function can only be the result of a single sub-query. It's essentially the same as a parameterised view, because views demonstrate this same behaviour of extracting the definition of the view and using it in the outer query. A multi-statement function is clearly more powerful because it can contain far more complex logic.

But a multi-statement function isn't really a function at all. It's a stored procedure. It's wrapped up like a function, but behaves like a stored procedure. It would be completely unreasonable to expect that a stored procedure could be simplified down to recognise that not all the columns might be needed, but yet this is part of the pain associated with this procedural function situation.

The biggest clue that a multi-statement function is more like a stored procedure than a function is the "BEGIN" and "END" statements that surround the code. If you try to create a multi-statement function without these statements, you'll get an error – they are very much required. When I used to present on this kind of thing, I even used to call it "The Dangers of BEGIN and END", and yes, I've written about this type of thing before in a similarly-named post over at my old blog.

Now how about scalar functions…

Suppose we wanted a scalar function to return the count of these.

Notice the evil words? They're required. Try to remove them, you just get an error.

That's right – any scalar function is procedural, despite the fact that you wrap up a sub-query inside that RETURN statement. It's as ugly as anything. Hopefully this will change in future versions.

Let's have a look at how this is reflected in an execution plan. Here's a query, its Actual plan, and its Estimated plan:



We see here that the cost of the scalar function is about twice that of the outer query. Nicely, the query optimizer has worked out that it doesn't need the Employee table, but that's a bit of a red herring here. There's actually something way more significant going on.

If I look at the properties of that UDF operator, it tells me that the Estimated Subtree Cost is 0.337999.


If I just run the query SELECT dbo.FetchSales_scalar(281,2003); we see that the UDF cost is still unchanged.


You see, this 0.0337999 is the cost of running the scalar function ONCE.

But when we ran that query with the CROSS JOIN in it, we returned quite a few rows. 68 in fact. Could've been a lot more, if we'd had more salespeople or more years.


And so we come to the biggest problem. This procedure (I don't want to call it a function) is getting called 68 times – each one between twice as expensive as the outer query. And because it's calling it in a separate context, there is even more overhead that I haven't considered here.

The cheek of it, to say that the Compute Scalar operator here costs 0%! I know a number of IT projects that could've used that kind of costing method, but that's another story that I'm not going to go into here.

Let's look at a better way.

Suppose our scalar function had been implemented as an inline one. Then it could have been expanded out like a sub-query. It could've run something like this:


Don't worry too much about the Scan of the SalesOrderHeader underneath a Nested Loop. If you remember from plenty of other posts on the matter, execution plans don't push the data through. That Scan only runs once. The Index Spool sucks the data out of it and populates a structure that is used to feed the Stream Aggregate. The Index Spool operator gets called 68 times, but the Scan only once (the Number of Executions property demonstrates this).

Here, the Query Optimizer has a full picture of what's being asked, and can make the appropriate decision about how it accesses the data. It can simplify it down properly.

To get this kind of behaviour from a function, we need it to be inline. But without inline scalar functions, we need to make our function be table-valued. Luckily, that's ok.

But we can't use this as a scalar. Instead, we need to use it with the APPLY operator.

And now, we get the plan that we want for this query.


All we've done is tell the function that it's returning a table instead of a single value, and removed the BEGIN and END statements. We've had to name the column being returned, but what we've gained is an actual inline simplifiable function. And if we wanted it to return multiple columns, it could do that too. I really consider this function to be superior to the scalar function in every way.

It does need to be handled differently in the outer query, but in many ways it's a more elegant method there too. The function calls can be put amongst the FROM clause, where they can then be used in the WHERE or GROUP BY clauses without fear of calling the function multiple times (another horrible side effect of functions).

So please. If you see BEGIN and END in a function, remember it's not really a function, it's a procedure. And then fix it.