This entry illustrates that when a report property is changed within Report Manager for SQL Server Reporting Services, that change does not actually become part of the RDL definition.

How the Discovery was Made

Developer Ted deployed a report, using BIDS, to the Development environment. This was a brand new report that hadn’t existed in QA or Prod previously.
The RDL definition was then passed to DBA Joe for deployment to the QA environment.
While in QA, DBA Joe made a change to the report’s default parameter value within Report Manager.
Then, thinking the parameter choice would be retained, DBA Joe downloaded the RDL from Report Manager in QA. This RDL version was migrated to Production.
It was discovered that the default parameter value which was set in QA didn’t make it to Production - it was the same as it was in the Development environment.

Steps To Reproduce this Behavior

Open Report Manager (http://localhost/reports) and navigate to your AdventureWorks 2008 Sample Reports folder.
Select “Manage” from the drop-down for the “Company Sales 2008” report.

On the Parameters page, note that the default EndDate parameter value is 12/31/2003. Change this default to be 6/30/2003. For grins, let’s also change the Display Text to be “End Date New.” Click Apply.

Run the report to confirm the EndDate label and default value are changed.
Return the folder for AdventureWorks 2008 Sample Reports. Choose “Download” from the drop-down for the Company Sales 2008 report. Save it wherever you’d like. (The download will want to put underscores for the spaces in the name – normally we’d correct that to make sure it doesn’t change but in this case it’s fine to leave the underscores in the name.)

Now, click the Upload File button in the menu. Select the RDL file we just downloaded. Give it a name of “Company_Sales_2008_New” because we must create a brand new report to reproduce this behavior (explained in the “Existing Report Versus New Report” section below). Click OK.

Select Manage from the drop-down menu for the new report just uploaded. On the Parameters page you’ll see the label and default value for EndDate are unchanged from the original file – meaning these property settings weren’t in the RDL file we downloaded.

Optional: If you’d actually like to run the new report just uploaded, go to the Data Sources tab and associate it to the AdventureWorks2008 data source.

Existing Report Versus New Report

Now that we know property settings changed in Report Manager aren’t actually part of the RDL, the next thing to be aware of is the difference in behavior when we have an existing report as opposed to a new report. If, in our “Steps to Reproduce this Behavior” section above, we had chosen to overwrite the existing file rather than specify a new report name, then Report Manager would have retained our new End Date settings after we redeployed the new version of the report. This is a nice convenience – basically Report Manager gets to “trump” whatever was redeployed – also meaning that DBA Joe’s settings win out over Developer Ted’s settings which usually makes perfect sense for administration purposes.

However, when a new report is involved, Report Manager does not have the ability to retain a setting which was changed only in Report Manager. For a new report, or the same report in a new environment, the setting will need to be reestablished. For parameter defaults, you could also opt to redeploy using BIDS which would make it part of the RDL. However, BIDS is not an option for those properties which are only available in Report Manager (such as caching, subscriptions, and snapshots).

As far as I’m aware, Report Manager’s differing behavior between existing reports and new reports applies to all versions. The above screen shots were taken with SQL Server Reporting Services 2008 R2.