SSRS report parameters set after publishing to report manager

Hello experts -

We are in the process of migrating from SSRS 2005 to SSRS 2008 and have come across an issue with default report parameters set at the design level (in SSRS before deploying) vs. report parameters set at the report manger level (in the web interface after publishing). One of our developers has written a script to extract all the reports from the 2005 collection and drop it into the 2008 collection.  The default report parameters that are set at the report manager level (after deploying) are not migrating but the default report parameters that are set at the design level in SSRS are.

I am wondering if there is a way to find out which default report parameters are set after deployment? I found a script (attached) to give me default report parameters that have been setup in SSRS, which is the first half of the equation. However, I am hoping that there is a place in the ReportServer database (or maybe somewhere else?) that will tell me if default report parameters are setup in report manager, along with what those reports and parameters are.

I hope all that made sense. I know I rambled a bit...
Find-Reports-with-Defaults.docx
Lisa CallahanBusiness Intelligence AnalystAsked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
Megan BrooksConnect With a Mentor SQL Server ConsultantCommented:
It makes a lot of sense. "By design" Report Server preserves certain parameter settings once a report has been published. Exactly when it ignores new published settings and when it overwrites saved settings is a mystery I have never wanted to spend a lot of time figuring out. Instead, I have usually followed a process something like this:

1. Publish an update to a report
2. Validate the report
3. If it doesn't work as expected, delete it from the report server and publish again.
4. If it still doesn't work, there is a problem with the report itself and not with however Report Server decided to mangle the parameter settings.

An alternative to #3 is to manually go into Report Manager (on the Report Server) and change the parameter properties to match what is currently in the RDL published in step 1. This can avoid having to delete. If the properties don't change often and you don't want to delete, this may be the solution.

Deleting a report before republishing doesn't matter in simple reports, but it can wipe out history information, as well as caching and snapshots, subscriptions, etc.

It should be possible to write automation to check for and correct discrepancies between published parameters and those in the RDL being published, using the catalog web service. I've never had to go that far, and I don't know what surprises you might run into.
0
All Courses

From novice to tech pro — start learning today.