Comments on: Use Stored Procedure Output Parameters in SSRS

By: Cool Paper Airplanes

Cool Paper Airplanes — Fri, 08 Jan 2010 13:29:31 +0000

This is what I’ve been looking for! Thank you so much for sharing this!

By: Alex

Alex — Fri, 05 Dec 2008 10:03:24 +0000

Thanks for your comment Drikus, and that’s a very nice way of getting the info out.

The problem in most situations is that the return value from stored procs are status flags (did the proc work?, what state is the base data in, what kind of data is being returned etc. etc.), which is additional data, not derived from the dataset. Even in this situation though, the best solution is to edit the stored proc and append the value to the dataset as you’ve pointed out. However in many situations the poor old report developer is not allowed to edit the source stored proc, so must find a workaround.

Like any workaround, there is always a hit somewhere, and you’re right that temporary tables are best avoided if at all possible, not least as they are not supported very well in SSRS!.

And yes, I was using SQL 2005 – I should really make that clear in posts – point noted thanks!

By: Drikus.Roux

Drikus.Roux — Fri, 05 Dec 2008 09:35:14 +0000

Judging by the date of you post, you must be using SQL 2005 with SSRS 2005.

Not that I don’t appreciate the gymnastics you have performed, but if your OUTPUT value can be derived from a sub-query, e.g. rowcount or applying an aggregate function, e.g. SUM() on your data, you could leverage something like:

CAST(COUNT(RecordID) OVER (PARTITION BY 1) AS VARCHAR(9)) AS [RecordCount] <– Partition by 1 to get a total number of records count value, which you could also have done with @@RowCount via OUTPUT param, which of course you can’t use in SSRS.

Then you use the =First(Fields!Output.Value) as you suggested in the report. At least you don’t have to deal with temp tables, all that IO to tempdb and the administration of cleaning up afterwards.

Hope this is of some use!