When I tried to change and save the settings on one of the reports, I was presented with this error:

The user or group name ‘Dom\User.Name’ is not recognized. (rsUnknownUserName)

Now, it turned out that the user that had originally create this report subscription had recently been deleted out of the active directory, and there was a lot of reports that this user had created. I had a poke around on the web interface and in the management tools, but i couldn’t see anywhere to change the owner of the subscription.

So, as i’ve had to do in the past I started having a look in the reporting service database. I looked first in the Subscriptions table, and there was an OwnerID field, when I linked this table back to the users table I found it was indeed linked to the old user that had been removed. So, I found a valid user in the table, and ran this SQL to update the Subscriptions table pointing to this user:

UPDATE dbo.Subscriptions SET OwnerID = ‘xxx-xxx-xxx-xxx-New-User’ WHERE OwnerID = ‘xxx-xxx-xxx-xxx-Old-User’

When I opened up the subscription again, the owner was now valid, and I could save the report without the error message. I’m glad i did’nt have to go back to the user and tell them they needed to re-create all the subscriptions!

Parameters are you friend

The first thing to do is create yourself a new parameter in the report, and call it something like par_expand_groups. Give it the following options:

Now, you need to make this parameter control weather or not the group is expanded as the report is ran, you do this by putting an expression into the hidden property of the row.

Normally if you have a group, when you run the report it will probably be hidden and the user has the option of showing the details, so the hidden property will be set to true. We are going to set it to the following expression:

=IIF(Parameters!par_expand_groups.Value = “True”, False, True)

This means that if the parameter is set to yes, the details will be shown, if its set to no they will remain hidden. Add this to each level of grouping on your report, and the user now has control over what they see

Slight Problem with the show/hide icons

Once you have added this to your report, you might notice a slight problem. If you run the report with the option of showing the group details, the little show/hide icon on the left used to toggle the details will be wrong. It will be showing the ‘+’ even though the details are already showing, and if you press it to hide the details it will change to a ‘-’. They are the wrong way round!

Obviously, this is going to confuse your users, and needs sorting. Well, thanks to a tip from http://www.lukehayler.com/2009/07/custom-visibility-toggling-in-ssrs its easy.

All you need to do is open up the properties of the text box that is the trigger for the show hide, and go into the Visibility tab. At the bottom is an  option to set an expression for the toggle image. just enter:

=IIF(Parameters!par_expand_groups.Value = “True”, True, False)

As before, they is just looking at your parameter and setting the value of the toggle image. Now, when you run the report with the option to display the details, they icons for toggling the details should be correct.

‘Cannot load client print control’

Turns out that one of the patches Microsoft issue out (on a seemingly never ending basis) breaks(well, blocks) the activex. The patch in question is the ActiveX killbit one (i cant remember the kb number), there appears to be a problem with the old version of the print control activex, and when the latest patch is applied to the clients it stops the print control working.

The way to get it working again is basilcly to patch your reports server. This is something i am always a bit cautious of doing, as in the past i have had problems (service pack one removed the ability to do a multi select parameter) but this time i had a virtual server i could snapshot, patch then test.

To get it working again, i installed first of all SQL 2005 service pack 2 (http://www.microsoft.com/downloads/details.aspx?FamilyId=d07219b2-1e23-49c8-8f0c-63fa18f26d3a&displaylang=en), then the latest hotfix rollup (http://support.microsoft.com/kb/956854). On a couple of the client machines this seemed to fix the problem without having to re-download the control, but on others we had to remove the control first, then re-install it and it worked a treat

a) setting the report data source at run time and
b) letting the users control the database they want to connect to. Some high level user need to be able to access multiple databases, while others will just need access to their local one

So, here’s how I went about doing it.

Setting Data source at Run time

Normally, when you setup a reports data source in reporting services, you just point it to the database you want it to use (probably using a shared data source) give it some credentials and off you go. You would probably end up with a connection string looking something like this:

Under normal circumstances that would work fine. But not this time. I need an easy way to replace the information held in the connection string with some sort of variable.

Turns out the easiest way to do it is by using a parameter in the connection string. You can create the connection string as an expression as if you were working with any other part of the report. However, before doing this you first need to create the parameters and fill them with some data.

Data Source Table

In the reports database, I created two new tables, one that will hold the name of the reports servers, database names and Active directory group with access to this data source. The other one will contain all the user names and what Database they are currently using. Download the SQL scrip to create the databases below

hello

Run this script on your reports sever database, and you will have two new tables, database_details and user_details. In order to do the tests you will need to create an entry in the database table (database_details) for your database, and an entry in the user table (user_details) for your username (include the domain name so it should read dom\joe.bloggs) and point it using the site_id filed to the database. You are now ready to create the SQL in the report that will populate the parameters

Dataset Containing the database connection details

Create yourself a test report, and in that report create a new dataset that points at your reports server database. The SQL needs to be the following:

SELECT     jp_user_details.username, jp_database_details.server_name, jp_database_details.database_name
FROM         jp_user_details INNER JOIN
jp_database_details ON jp_user_details.site_id = jp_database_details.site_id

This will return all the names in your database, what we need to do now is make sure at run time it only returns data for the user running the report. To do that we need to put a filter on the report. The filter will be:

Fields!username.value=User!UserID

and should look like this in your Dataset properties

The Parameters

Once you have done this dataset, you need to create a couple of parameters. One will be for the server name, one for the database name. So go into your report parameters and create the following, with these options:

Name – ServerName
Datatype - String
Hidden - Yes
Available Values from Query: Select your dataset , then both values fields need to be server_name
Default Values From Query – Select your dataset, value field is server_name

Name – DatabaseName
Datatype - String
Hidden - Yes
Available Values from Query: Select your dataset , then both values fields need to be database_name
Default Values From Query – Select your dataset, value field is database_name

What does this do? Well, when you run your report now you will have the two parameters you have just created filled in with the server name and database name the person running the report wants to report on. The parameters are set to hidden so the user knows nothing about them.

Final Step, create your dynamic dataset

Now we have everything we need in place, the last step is to create a dataset that will look into the server held agaist the user, and retrive us the actul information we want. Create a new dataset, and in the connection string of this data source put the following:

= “data source=” & Parameters!ServerName.Value & “;initial catalog=” &  Parameters!DatabaseName.Value

It should look like this in the window

Now when you run the report, you data source will be based on the users choice held in the table

A couple of things to note

You will find it hard (probably impossable) to write the report with the parameterized data source. You’ll need to work with your local copy of the database hardcodded into the connection string first, then when you are happy with it change it to the parameter driven one. If you dont do this the report designer wont be able to read the dataset.

You also need to be carful the order in witch you put your user paramters on the report. I found that if i did’nt put data driven parameters (ie a list of sales areas the user can select) at the top of the list, they were greyed out when you tried to run the report. Not sure why, but i asume its down the the order the datasets are exceuted in

If you have any problems with this, or have any different ways of doing it let me know!

Reports Timing out – This is a pain. I have a couple of reports that people run huge queries for, and sometimes the reports can time out while running. This was a fairly easy fix, just locate your rsreportserver.config file (mine was in (Program Files\Microsoft SQL Server\MSSQL.2\Reporting Services\ReportServer). Open it up and alter the key:

DatabaseQueryTimeout- This is the amount of time the reports server will wait until it thinks the query to the server has timed out. You can set it to 0 (zero) for no timeout, but this is probably not a good idea. There is another key in there I thought might also help called SQLCommandTimeoutSeconds but according to the MS docs this is not used (so why the hell is it in there?)

Better Client Side Errors – Fault finding errors in the report viewer can be a bit painful, but you can enable remote errors to help you out a bit.
There  is a table in the reports server database called ConfigurationInfo. In here there is a EnableRemoteErrors property. If you set this to true and restart the reporting service clients will get better errors, helping you try and work out what is actually happening.

My next step with errors is to try and handle them properly in the reports. There is a ReportError event witch I think will do the trick. When I have worked out the best way to use it i will post about it here

Logs – As well as writing to the application event log, reporting services also write more detailed information into its own log files. These (along with crash dump files) can be found in C:\Program Files\Microsoft SQL Server\MSSQL.2\Reporting Services\LogFiles.

Using all this info I now find it easier to troubleshoot and tweek my environment. If anyone else has any handy hints let me know and ill add them to this post!

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.

Changing the Image

The will be some circumstances where you want to show a different image depending on the value of a variable. This is done in a similar way to hiding the image, but instead you Data value of the image source.

The first thing to do is insert the images you need onto the report. Drop an image control onto your table where you want it to apear, and embed the image into the report. Then drop another image control on the report, maybe in the header or somewhere out of the way. Embed the image again and this time set this controls Visible property to false. Now you have both the images you need in the report.

At this point make a note of the names of both of the images embedded in the report. They tend to be the name of the file you used without the extension.

Now, go into the property’s of the image control in the table, under Data -> Value drop down to Expression to open up the expression editor. Here we are going to use an IIF statement on a filed, and tell it to use one image if the condition is true, or a different one if it was false:

=iif(Fields!Stop_date.Value is nothing, “advert_incomplete_1″, “stop”)

When you save it you wont see the image in the box any more, it should have changed to this

Now, when you run the report, the images should swap round depending on what the value of your filed is, so you will end up with something like

Hopefully, you should now be able to make better use of images in your reports now, making them a bit better to look at and by using visual pointers instead of plain old text.

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

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

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

You know what its like, most accounts type people insist on working Excel (even though you could just change the report to suit them), but sometimes when you export the report to excel extra columns appear. Then, you can export the same report again and the extra columns you had before will no longer be there. The problem accounts people have with the extra columns is it stuffs up any sorting they want to do, and any macros they have written that depend on specific data being in specific places.

The best way to get round this seams to be to remove all the dynamic text boxes etc from the headers and footers of the report. I think what must happen is if the info in the headers doesn’t align exactly with the tables in the main section of the report, it throws off the export.

I’ve now got two copies of the reports that the accounts people tend to use, one with the headers and footers still in, and one they can use to export into excel.