One of the big advantages SQL reporting services 2005 has over 2000 is the ability to use Muil-Value parameters (I cant really believe it was missing from 2000)

The only problem with them is showing the values of the parameters you have selected on the report, or showing and ‘ALL’ value if the user has selected all available ones. This is a walk through of how to do it, although I’m sure there is a better way out there.

First of all were are going to assume you have a big lift of parameters (say 20+), if you selected them all then you would get a huge ugly list where you show them on the report probably looking something like this:

Now, this does not look very nice on the report, will probably make the report go onto 2 pages when it would fit on one etc. What we want to do in this situation is just output the word ‘ALL’. In order to do this you need to create a new dataset based on the number of possible values in the parameter, and add some logic to the text box that displays the values

Creating the data source

First of all create a new dataset and call it data_param_count or similar. Then copy the sql from what you use to get your parameter option, and instead of selecting all the fields use a SQL select count query to just return the number of rows, eg:

Select Count (*) from tbl_params

This should return you just one row from your table that contains the number of parameters that you can select. We can then use this in our text box to find out the number of parameters we are dealing with.

Displaying the parameter Value

Now that you know how many parameters you are dealing with, you are ready to output them. Drop an text box onto your report, at the top of the body section (you cant drop it into the header as when the header is rendered the data sources have not yet ran). Right click on the new text box and select Expression to open up the expression editor.

You now need to tell the text box to display the contents of the parameter, something if there are too many to display (such as ‘Cannot display all’) and something for if they are all selected (such as ‘ALL’). In order to do this you need to use a couple of functions built into reporting services IIF and Join, these will allow us to check the number of parameters and output what we want. Here’s a code example:

= “Param: ” & IIF(Sum(Fields!ID.Value, “data_param_count”) = Parameters!par_List.Count,”All”,Join(Parameters!par_List.Value, “,”))

So, what’s happening in this line of code?

• First of all we use an IIF to see if the overall number of parameters available to select is equal to the number the user has chosen. We can get how many have been selected using the count property of the parameter object
• Next if the part of the IIF that will run if the statement is true. So here if the count of selected params is the same as the number available we output the string ‘ALL’
• The final part is what happens if the statement is not true. We use the Join function to output a list of all the parameters the user has selected, separated by a comma. Now instead of a long list if you select all the available values, you will get this:

That’s far neater than just outputting a long list. If you wanted to show something else in a case where lots of values(but not all) have been selected, you could just add another IIF statement into the above in the place of the false string that could check for something like more than 10, and display ‘To many to Display’ or something similar.

Images. They can make your reports look great, but sometimes they are a bit tricky to show where you want, and when you want. Even something as simple as showing an image or not, or showing a different image based on the condition of some data.

Well, it might not be rocket science (or rocket engineering) but its not exactly well documented, so here are a couple of real world examples of how to handle images in your reports.

Showing/Hiding Images

First of all this is how to show or hide an image in a table, based on the condition of filed in your data set. This could be used to indicate (for instance) if an order is stopped. The first thing to do is add an image holder into your table. When you drag the image holder onto the cell of the table the image wizard will open. Follow the Wizard through and embed the image in your report. When its done you will see the image in the table cell.

Now, on the properties of the cell, drop down the Visible -> Hidden property, and click in Expression in the list, this will open up the expression editor. In here we are going to use an IIF statement to check the condition of one of our fields. We can then set the Visible state to true or false depending on the outcome. The statement will look something like:

=iif(Fields!Stop_Stat.Value = “Stop”, False, True)

With this now in place, when you run the report it should now only show the image when the value of Stop_Stat is true.

Over the weekend we did a big upgrade, part of witch meant all the reports had to be recreated to work with the new database schema, so I told people they would have to setup any subscriptions again.

First of all I think the being able to create subscriptions is a great idea. The only downside to it is having to specify a username/password to run as (i’m not sure how you could get round this though apart from running all the subscription reports as a specific user), and the fact that it has no built in print functionally.

To get round the lack of printing, we use a product call batch print pro, available from traction-software.co.uk. It is a fantastic piece of software that you point at a directory, and it monitors in there for PDF files and sends them to a printer you specify as they drop in. The setup of it is sometimes a bit odd but it worked well.

Anyway, a user created her subscriptions again but could not edit them once they changed, she kept getting an error when hitting save:

An internal error occurred on the report server. See the error log for more details. (rsInternalError)
The EXECUTE permission was denied on the object ‘sp_add_category’, database ‘msdb’, schema ‘dbo’.

For some reason, when I looked on the reports server config, the windows service identity section was in an error state. I just put the username and password back in, and it worked again. I didn’t even have to restart reporting services

Over the weekend we did a big upgrade, part of witch meant all the reports had to be recreated to work with the new database schema, so I told people they would have to setup any subscriptions again.

First of all I think the being able to create subscriptions is a great idea. The only downside to it is having to specify a username/password to run as (i’m not sure how you could get round this though apart from running all the subscription reports as a specific user), and the fact that it has no built in print functionally.

To get round the lack of printing, we use a product call batch print pro, available from traction-software.co.uk. It is a fantastic piece of software that you point at a directory, and it monitors in there for PDF files and sends them to a printer you specify as they drop in. The setup of it is sometimes a bit odd but it worked well.

Anyway, a user created her subscriptions again but could not edit them once they changed, she kept getting an error when hitting save:

An internal error occurred on the report server. See the error log for more details. (rsInternalError) Get Online Help

For some reason, when I looked on the reports server config, the windows service identity section was in an error state. I just put the username and password back in, and it worked again. I didn’t even have to restart reporting services