Yes, I’m sorry, this is yet another post showing how much better life is<\/a> when you do not expose users to the Report Manager, or vice-versa.<\/p>\n<\/blockquote>\n Setting the ReportViewer.ServerReport.ReportPath value to a linked report works fine, as you’d expect. I use a little code to set the value of the hidden parameter in the Load for the page, like so:<\/p>\n I won’t belabor this, because I’ve shown this type of technique<\/a> a number of times before. You might think I didn’t need the linked report since I could dynamically hide the security parameter, as shown above.<\/p>\n But I wanted the initial report to allow for drilldowns into more detailed reports, preserving not only the value of the hidden security parameter but also the choices the user had made in the visible parameters. I wanted to ensure that, even when no code was involved to set the security parameter (definitely in a postback, possibly in a report link action), the security parameter remained hidden.<\/p>\n Normally, you’d implement this drilldown using the action type “Go to report” and then set the parameters in the drilldown using the values from the current report. But I found that I couldn’t get the linked reports to show up when I Browsed the server — because they’re not actually RDLs — and of course, without the Browse, the dialog can’t provide those nice lists of settable parameters for “Go to report”. <\/p>\n To illustrate that happy path, here’s what you would normally expect to do and see:<\/p>\n I couldn’t get the linked report to show up in the Browse, so I just figured I couldn’t use “Go to report” for linked reports. <\/p>\n Instead, I wrote a bunch of code that re-accessed the current web application page, and passed all the user-settable parameter information, using the “Go to URL” action. My thinking and method was as follows:<\/p>\n Why didn’t I just try it? <\/p>\n You know (and I certainly do) that you can use an expression in the “Go to report” Action, although, when you do, the Report Builder or Designer can’t show you a handy list of parameters by interrogating the RDL on the server.<\/p>\n Using linked reports in the “Go to report” action works just fine. Go on, just type it in. <\/em>(Or, if you need to, use an expression to reference it.) Then type in the parameter passing the way you would for an RDL specified as an expression. <\/p>\n The linked report takes care of hiding the security parameter automatically, of course, multi-valued parameters are also automatically handled, of course, and the world is a good place.<\/p>\n It even works fine if there are spaces in the report path, with no need to encode or translate the spaces.<\/p>\n You can even get the parameter drop downs to work. Just Browse to the original RDL first, and then manually correct the “Specify a report” textbox to be the path and name of the linked copy. The parameter dropdowns will be available when you press the “Add” button, because apparently they are loaded for the Browsed report and don’t get unloaded when you type in the replacement.<\/p>\n Maybe that’s a bug, but if it is, don’t tell anybody.<\/p>\n<\/blockquote>\n I included that longish code block mostly so you can see that, even in this limited sketch, it’s an annoying amount of code. (In the actual, production version it’s quite a bit longer, and a little more performant, but not much.) But I guess you might have a real need to set a bunch of reportviewer-hosted parameters dynamically, some time, from a RESTful web call or something. Right now I can’t think of a scenario that requires it, but drop me a line if you do.<\/p>\n","protected":false},"excerpt":{"rendered":" I have a situation in which I need to use linked reports in a ReportViewer web control. One of the parameters — which, if you viewed it in the Report Manager, would be visible — should not be seen by most viewers, because it sets security information for the report according to complex criteria. TheRead more<\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,5,12],"tags":[],"class_list":["post-19","post","type-post","status-publish","format-standard","hentry","category-asp-net","category-reporting","category-yaps"],"_links":{"self":[{"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/posts\/19","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/comments?post=19"}],"version-history":[{"count":0,"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/posts\/19\/revisions"}],"wp:attachment":[{"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/media?parent=19"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/categories?post=19"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/spacefold.com\/lisa\/wp-json\/wp\/v2\/tags?post=19"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}} param(0) = New ReportParameter(\"X\", \"123456\", 0)\n ' The first argument (X) is the parameter name.\n ' The second argument (\"123456\") is the value of the parameter, \n ' and actually takes a bunch of work to figure out,\n ' not included because your rules would be completely different.\n ' The third arg hides the parameter in the parameter panel\n ' of the report viewer control. It is mostly for emphasis here.\n<\/pre>\n
Here’s where I got flustered<\/h2>\n
<\/p>\n
So, like an idiot<\/h2>\n
\n
\"http:\/\/MyServer\/Default.aspx?ReportPath={0}\"<\/code><\/li>\nString.Format(Parameters!LinkURL.Value, \"LinkedReport\") & \"&y=\" & <\/code> Parameters!y.Value.Join(\",\") & \"&z=\" & Parameters!z.Value.ToString()<\/code>
… where y and z are the user-settable parameters and y is a multi-valued parameter.<\/li>\n
Dim rp As String = Request.QueryString(\"ReportPath\")\n If Not Me.IsPostBack() Then \n ' you will need to be careful about postbacks if you are going back to the same report for any reaspon.\n With Me.ReportViewer1.ServerReport\n If Len(rp) > 0 Then\n .ReportPath = rp\n Else\n ' you can choose whether to set a default here or not, \n ' set it in the configuration of the report viewer control, etc... \n End If\n Dim numparams As Integer = 0\n For Each p In Request.QueryString\n If p <> \"ReportPath\" AndAlso p <> \"X\" Then \n ' X is the one we always want to pass to send security info;\n ' if the user took a look at the query string and decided to send it,\n ' we would want to ignore that information, obvs.\n numparams += 1\n End If\n Next\n ' handle the non-user-settable security information:\n Dim param(numparams) As ReportParameter\n param(0) = New ReportParameter(\"X\", \"123456\", 0)\n ' third arg hides the parameter, just for emphasis, although it is already hidden in the linked report\n If numparams > 0 Then\n Dim ps As String()\n Dim i As Integer = 1\n For Each p In Request.QueryString.Keys\n If p <> \"ReportPath\" AndAlso p <> \"X\" Then\n ' in the production version, I have built up\n ' a collection of settable params in the first block,\n ' rather than accessing the QueryString collection\n ' again here and having to evaluate these \n ' conditions a second time\n ps = Request.QueryString(p).Split(\",\")\n ' the Split will bring y back into an array form suitable for a multi-value param\n param(i) = New ReportParameter(p, ps, 1)\n ' third arg just emphasizes that this is a user-settable parameter, \n ' should they desire to re-set it and keep exploring after the drilldown.\n i += 1\n End If\n Next\n End If\n .SetParameters(param)\n End With\n End If<\/pre>\n
You’re probably way ahead of me<\/h2>\n
<\/p>\n
In fact<\/h3>\n
\n
Why bother<\/h2>\n