Groups | Blog | Home
all groups > sql server reporting services > december 2004 >

sql server reporting services : Non-prompted report parameter is Read-Only?



George Rice
12/4/2004 9:55:14 AM
Hi all,

I've got a dataset based on a stored proc which depends upon a single
parameter ("@ProdID"). When I execute the dataset on the Data , I am
prompted for the value and the results pane displays the properly restricted
values according to what I enter.

A report parameter called "ProdID" was also automatically generated, which
is automatically mapped to "@ProdID", and this is the issue. When I run the
report and pass this at the end of the querystring, "&ProdID=5555", the list
based upon the stored proc returns a properly restricted list according to
"ProdID". But, the "ProdID" parameter is rendered as visible on the report
at runtime, which is confusing to the user, throws off the design, etc.

I made the "ProdID" parameter go away by clearing the "Prompt" field (sp1
allows this), but now when I pass in the ProdID on the URL, I get the error:

"The report parameter 'ProdID' is read-only and cannot be modified.
(rsReadOnlyReportParameter)"

I've been searching Books Online, but haven't found this exact scenario yet.

I'm running WinServer Std with SRS sp1.

Any clues how to make the report parameter invisible AND not get the
"read-only" error? This should be simple.

Thanks in advance,

George Rice

Charles Kangai
12/4/2004 10:47:03 AM
If you are doing this from ASP/ASP.NET, you can use POST instead of GET. With
GET you put your parameters as part of a URL, which is what you are doing.
With POST, you can put your parameter values in hidden controls on a form.
Here is a simple example:

<HTML>
<body>
<FORM id="frmInfo" action="http://localhost/ReportServer?/Sales
Reports/ByTerritoryReport" method="POST" target="_self">
<INPUT type="hidden" name="rs:Command" value="Render">
<INPUT type="hidden" name="rc:LinkTarget" value="main">
<INPUT type="hidden" name="ProductID" value=5455>
<INPUT type="submit" value="Submit">
</FORM>
</body>
</HTML>

The user will now not see the parameters and cannot change them.

HTH

Charles Kangai, MCT, MCDBA

[quoted text, click to view]
George Rice
12/6/2004 11:18:56 AM
Hi Charles,

Thanks again for replying.

The one thing I've had to learn to live with is with asp.net you cannot
"Post" to another page (or anything else) without taking out the
"runat='server'" tag, as you did. This essentially makes it classic ASP. The
Form "action=" parameter has no effect in an aspx.net file. This means I
need a different aspx.net file for every different report I want to "Post"
to, unless I go with the classic model and skip the server-side processing,
meaning no Page_Load, etc... but this way I can build the "action" form
attribute dynamically using the classic syntax:
target=<%=http://whatever.com%>

With that in mind, I still did exactly what you stated in your reply, and
using hidden fields and the form post, I still get the error:

a.. The report parameter ProdID' is read-only and cannot be modified.
(rsReadOnlyReportParameter) Get Online Help
I've got the "ProdID" parameter prompt cleared (under Report Parameters) so
it doesn't show up on the form, and it seems that no matter how you cut it,
that makes it "ReadOnly" whether you do a GET or a POST. I've read that SRS
SP1 was supposed to fix that, but apparently not, at least not on my
machine.

There is some good discussion at this URL:
http://geekswithblogs.net/gobrien/archive/2004/07/30/9116.aspx

I've tried one of the suggestions, setting on the URL:
"&rc:Parameters=false" but then I get an error that the parameter I'm trying
to pass in doesn't exist, which makes sense, because I just set it to false.

I just can't seem to win. I've found no way to pass in a parameter to a
stored proc via 1) a URL nor 2) posting with hidden fields (using classic
ASP), so I'm stumped.

Am I going to have to wait for SP2 or V2 or is there still hope?

Thanks in advance to anybody who has any clues about this,

-George Rice, MCSD.NET





[quoted text, click to view]

Lev Semenets [MSFT]
12/6/2004 10:31:35 PM
check Reporting Services SP1 readme.htm file. It should describe how to make
hidden parameter
Also, Report Designer may create hidden parameter if you set Prompt to
blanks

--
This posting is provided "AS IS" with no warranties, and confers no rights.


[quoted text, click to view]

George Rice
12/7/2004 10:18:58 AM
Thanks for your reply,

The readme states:

"In SP1, you can clear the Prompt User check box to hide the parameter
fields and values in the report. Doing so does not introduce restrictions on
how you subsequently set the parameter value externally at run time."

This has not been my experience, and from what I've read out there, I'm not
alone.

- In Report Designer, Clearing the Prompt User checkbox in Report Parameters
produces the following error when passing a param on the URL with the same
name:

a.. The report parameter 'User_ID' is read-only and cannot be modified.
(rsReadOnlyReportParameter) Get Online Help
- In Report Manager, Clearing the Prompt User AND the Prompt String produces
the same error.
- Checking the Prompt User and clearing the prompt string displays the
parameter (from the URL) as the first item in the form.

All of these scenarios are not just in preview, but deployed to a server.
I'm running Windows 2003 and SRS Dev. Edition SP1.

Do you have a clue what I'm doing wrong? Has anybody actually succeeded in
passing in a "hidden" parameter that does not display on the UI?

-George Rice




[quoted text, click to view]

Rick
12/7/2004 1:15:06 PM
I'm trying to do the same thing, except that I'm attempting to use the "Jump
to report" navigation feature, and I'm experiencing EXACTLY the same problem!

This has got to be a bug. I can't understand why a non-prompted parameter
would be read-only. (I'd pretty much be done with my project now if it
weren't for this...)

I too am running on Windows 2003 and Reporting Services w/SP1.

Lev Semenets [MSFT]
12/7/2004 8:56:13 PM
this is by design in V1. Prompless parameter is read-only. You can change it
to hidden parameter using Report Manager or script (see
http://blogs.msdn.com/levs/archive/2004/07/20/189178.aspx for sample of such
script)

--
This posting is provided "AS IS" with no warranties, and confers no rights.


[quoted text, click to view]

Lev Semenets [MSFT]
12/7/2004 8:58:27 PM
In Report Manager, do not clear Prompt String and clear Prompt User
checkbox. Parameter will be hidden.

--
This posting is provided "AS IS" with no warranties, and confers no rights.


[quoted text, click to view]

Rick
12/8/2004 7:59:01 AM
Lev,

To the best of my knowledge I've tried both of your suggestions without
success.

1. I've run the script you posted which set the parameter in Report Manager
to "Prompt User" checked and "Prompt String" <empty>. When the report is
invoked I get a error at line 82, character 2, error: object required.

2. When I uncheck "Prompt User" and set "Prompt String" <empty> the report
will run without error. However, calling it from another report yields the
"read-only parameter" error.

If it helps -- the parameter's name in the report designer is 'ProjectID',
prompt is <empty>, data type is integer and is marked as "allow null value"
with available values set to non-queried and default values set to 'none'.

My simplistic solution is from Microsoft to remove the read-only restriction
from promptless parameters.

Rick

[quoted text, click to view]
George Rice
12/8/2004 2:25:40 PM
Hi,

Thanks for the replies.

I have succeeded in getting simple input params to be hidden: in Report
Manager, do NOT clear the Prompt User box and clear the prompt string. The
release notes for SP1 say to clear the prompt string, so that makes sense.
It seems that no matter how you cut it, unchecking the Prompt User box
causes the "Read-only" error.

Okay, so I've got a couple of input params that I can now hide, and I can
even pass them into a stored proc that fills appropriately according to the
matching dataset params. But, I have a short series of Cascading Parameters
that feed off of the first list which create a couple more cascading lists,
and of course those lists are built from report parameters.

I've tried your suggestion with clearing the checkbox and leaving the
prompt, and that didn't work (Read-only). I also ran the script you provided
in a different post to a successful completion, and the parameters were
still showing up on the deployed report.

It seems like it's all or nothing for hidden parameters. You can't hide the
"seed" parameters required to produce that first dataset and have the
cascaded (in my case) dropdown lists not hidden.

The code-behind:
'ReportViewer1.Parameters =
Microsoft.Samples.ReportingServices.ReportViewer.multiState.False

hides ALL of the parameters, but also renders them Read-only.

Regards,

George Rice, MCSD.NET




I'm now using the ReportViewer and setting the parameters form code-behind,
with identical results. It doesn't matter whether I use GETs, POSTs, or
code-behind, the parameters cannot be hidden, at least so far as I've
observed.

[quoted text, click to view]

George Rice
12/8/2004 3:02:39 PM
Hi again,

Might there be another approach?

For instance, if I set a public variable or variable in the report's code
section, might it be possible to set those variables from code-behind? Or
maybe set some hidden text boxes? Now that I'm using the ReportViewer
"control" on an aspx form, and I can programatically set the ServerUrl,
ReportPath, report parameters, etc., on the fly, one would think, hey?

Can I somehow grab ahold of the SessionID from within the report Code?

Just brainstorming. I need some way to get initial values into a report to
set up that first dataset.

-George Rice


[quoted text, click to view]

George Rice
12/8/2004 3:41:08 PM
Howdy,

Well I found a workaround that seems to work.

I created a linked report from Report Manager with the intention of having
everything be the same except for the properties of the 2 parameters I need
to pass in.

I cleared both the checkbox and the prompt string in my main report, set a
default of -1, and set up the same two parameters in the linked report with
Prompt User checked and Prompt String clear.

From code-behind, I then run the linked report instead of the actual report,
as such:

ReportViewer1.ServerUrl = "http://localhost/ReportServer"

ReportViewer1.ReportPath = "/Test/Representative_params"

ReportViewer1.SetParameter("User_ID", "5666")

ReportViewer1.SetParameter("AppID", "1")

Seems to work. I'd still like to know if it's possible to manipulate other
items as I outlined previously, but I'm somewhat happy now.

Also, because I created the linked report from Report Manager, I don't seem
have anything to grab on to, i.e., something I can put in SourceSafe and
say, "there it is." I know it exists in SQL Server, and I also know it has
no rdl code, so what does it have?

Thanks again in advance,

-George Rice



[quoted text, click to view]

George Rice
12/8/2004 4:13:46 PM
Howdy,

Well I found a workaround that seems to work.

I created a linked report from Report Manager with the intention of having
everything be the same except for the properties of the 2 parameters I need
to pass in.

I cleared both the checkbox and the prompt string in my main report, set a
default of -1, and set up the same two parameters in the linked report with
Prompt User checked and Prompt String clear.

From code-behind, I then run the linked report instead of the actual report,
as such:

ReportViewer1.ServerUrl = "http://localhost/ReportServer"
ReportViewer1.ReportPath = "/Test/Representative_params"
ReportViewer1.SetParameter("User_ID", "5666")
ReportViewer1.SetParameter("AppID", "1")

Seems to work. I'd still like to know if it's possible to manipulate other
items as I outlined previously, but I'm somewhat happy now.

Also, because I created the linked report from Report Manager, I don't seem
to have "physical" anything to grab on to, i.e., something I can put in
SourceSafe and
say, "there it is." I know it exists in SQL Server, and I also know it has
no rdl code, so how can I "versio" it?

Thanks again in advance,

-George Rice



[quoted text, click to view]


AddThis Social Bookmark Button