Home Dashboard Directory Help
Search

Default Non-queried SQL server 2008 reporting services report parameters not updated by RTalla


Status: 

Closed
 as Not Reproducible Help for as Not Reproducible


2
0
Sign in
to vote
Type: Bug
ID: 735121
Opened: 4/2/2012 2:48:10 PM
Access Restriction: Public
0
Workaround(s)
view
0
User(s) can reproduce this bug

Description

SQL Reporting Services Information
Name: Microsoft SQL Server 2008 Reporting Services
Edition: Enterprise Edition
Product Version: 10.0.1600.22

MS SQL Server 2008 Report Builder Version: 2.0

Issue: A report has been created with having 4 non queried parameters with default values and deployed onto SQL Reporting server. I ran the report from the server web manager to see the results, it went well and every thing was good.
Later on I opened the report in report builder and removed the default values for the non queried parameters and saved the report onto the server.

I want onto the server over again to check my default values are removed from the non queried parameters which would show as textboxes in the report view. Though i removed default values in the report builder and saved, still i am able to see default values on the server. To mu curiosity i tried in other way, I removed default values on server and tried to open in report builder. No luck, the changes which i made on server for non queried parameters are not showing up in report builder.

I know the server is the primary source so the changes which are made on server should reflect on report builder, but in my case the changes are not showing.


Any help/fix or suggestion is appreciated in this issue.
Details
Sign in to post a comment.
Posted by Microsoft on 4/19/2012 at 12:53 PM
Thanks for your feedback. I am resolving as Fixed. We addressed this issue in SQL Server 2008 R2 (Report Builder 3.0). I confirmed it no longer repros in that release.

Bob Meyers
SQL Server Reporting Services

Posted by Robert Heinig II on 4/16/2012 at 7:04 AM
This situation should be similar to what happens when one uses BIDS for report design and uses any of then built-in methods to update a rdl design (BIDS deploy, SSRS Manager replace, RS Script behave identically in this respect).

Note the following is my personal view, derived from experiments, guesswork and digging inundocumented internals, and half-forgotten after a vacation. The gist of it - 2 independent parameter sets by design - is definitely valid.

A published report has 2 separate Parameter lists specifying names, prompts, defaults (but not the queries supplying e.g. defaults) etc. One is in the rdl design (xml text) which the ReportServer database stores as an image column (ouch), the other is what the Management web frontend shows and allows to modify (the Parameter column in the ReportServer database, containing an XML fragment, with a schema differing from and partially contradicting the rdl schema, stored inefficiently in a ntext field). That's good, as management of published reports and basic design may be done by different people or divisions.

Updating a design seems to evaluate a yes/no decision whether the parameter definitions have changed. Depending on the result, treatment of the manager-side Parameter blob is different, and treatment of the base/master report and any linked reports is still a little different. If this is "no", then for exsample the Manager side Parameter blob of linked reports is not touched at all. If this is "yes", it is re-derived from the rdl and mostly overwritten, losing most of the work done by the SSRS manager department (e.g. modified prompts are lost). It sometimes decides incorrectly (e.g. it doesn't notice when you add a new available value to the list, but there were worse oversights I've forgotten - it misses changing type or nullability I think). Therefore, if you just change an 'available values' list, add a dummy parameter, republish, remove it, republish again.

For default values, the merging of "SSRS manager" and Designer work seems better as far as I remember, and in light of the division of labour between Reportserver management and designers, it is *by design* that modified defaults in rdl and the Reportserver catalog remain independent and will need to be copied manually, if appropriate. After all, the manager may have modified the defaults meaningfully to support specific requests!

I do concur, however, that more control over what happens with the designed parameter properties upon re-deployment would be very welcome.
Sign in to post a workaround.