Solved

SSRS report parameters set after publishing to report manager

Posted on 2016-10-06
1
55 Views
Last Modified: 2016-10-10
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
0
Comment
Question by:ldcallahan
1 Comment
 
LVL 14

Accepted Solution

by:
Megan Brooks earned 500 total points
ID: 41832519
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

Featured Post

DevOps Toolchain Recommendations

Read this Gartner Research Note and discover how your IT organization can automate and optimize DevOps processes using a toolchain architecture.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

This article explains how to reset the password of the sa account on a Microsoft SQL Server.  The steps in this article work in SQL 2005, 2008, 2008 R2, 2012, 2014 and 2016.
In this article we will get to know that how can we recover deleted data if it happens accidently. We really can recover deleted rows if we know the time when data is deleted by using the transaction log.
Along with being a a promotional video for my three-day Annielytics Dashboard Seminor, this Micro Tutorial is an intro to Google Analytics API data.
Microsoft Active Directory, the widely used IT infrastructure, is known for its high risk of credential theft. The best way to test your Active Directory’s vulnerabilities to pass-the-ticket, pass-the-hash, privilege escalation, and malware attacks …

773 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question