Print Parameter values on report
-
anyone know how to print parameter names and their values on the report itself? Perhaps some code to loop through the defined parameters and then plonk them on the page.
-
I use Visual Studio and all I do is place a text box in the report where I want it to display (ussually the header) and right click on it.
Expand Parameters and add the parameter you want to the text box by clicking on it one time and then click on insert. Click OK and look at the report in preview mode to see how it displays. You can also place a label next to the parameter if you wish. Hope this is what you are looking for.
Kurt Kracaw
-
Thanks. That's certainly one way. But, ideally, I'd like to build a template I can use with any report. Hence the idea of looping through the defined parameters using some code. This would require, for instance, picking up a variable which told you how many parameters the report had.
-
Hey Jon, I read your post and thought 'I want to do that!', and set about writing a function in the custom code to do it. But hit a snag that James Kovac hit in August, no collection support (see here for his take). Makes it nigh on impossible to get the parms programatically
Maybe (hopefully?) they've fixed this in 2005. Really not sure why they wouldn't have used IEnumerable or like James said, used System.Collections, but I guess it's easy to say not having had to write it
Steve.
-
That's a shame, but thanks for trying. I'm in the process of replacing an Ms Access-based report application which does loop through the relevant parameters on a front screen and prints the values on the report. Oh, well...
-
If you are interested in flexing you're dev muscles, i thought maybe the following *could* work, but it is dependant on certain security settings etc.
Basic requirement -> need the parameter (key) names for the parameters collection. If i have these in a string array I can then iterate through the collection in custom code within the report.
So, if I was to write an external assembly that contained a function that called the web service, I could get the parameter names for the particular report. The function would have to take the reportname as a parameter, in the first instance (ie cludgy job) you'd assume that the server was 'localhost' for contacting the webservice, but later you could mod the code to accept the web service url. There is also an assumption that the RS service 'user' has permissions to call the web service.
Ok, in the external dll, we just modify this sample (from BOL) to return a either a delimted string or preferably an array (i.e.whatever the custom code will allow as a return type)
using System;using System.Web.Services.Protocols;class Sample{ public static void Main() { ReportingService rs = new ReportingService(); rs.Credentials = System.Net.CredentialCache.DefaultCredentials; string report = "/SampleReports/Employee Sales Summary"; bool forRendering = false; string historyID = null; ParameterValue[] values = null; DataSourceCredentials[] credentials = null; ReportParameter[] parameters = null; try { parameters = rs.GetReportParameters(report, historyID, forRendering, values, credentials); if (parameters != null) { foreach (ReportParameter rp in parameters) { Console.WriteLine("Name: {0}", rp.Name); } } } catch (SoapException e) { Console.WriteLine(e.Detail.InnerXml.ToString()); } }}And that's it. As mentioned above, once you have the keys, you can easily interrogate the 'collection' to get the values.
If you do end up writing this, it would be good to post it to the script (?) section here, other could find it useful.
Cheers,
Steve.
-
Not having a development job per se(!), I can't pursue this in the short term, but it sounds like it might work. Anyone else out there want to give it a go and share the results with the rest of us?!
-
Hi Jon,
I sat down and wrote this tonight, and actually got it to work (woohoo). Basics are as described previously -> external assmebly that calls on the local reportserver web service using a passe in report name. This returns the parameters as a delimtied string to a sub in the custom code section, split the string to an array, use the array to get the parm names and the values. Call the sub (in custom code) from a text box in the header and on running the report, you get parm names and values in the textbox.
After i clean the code up a little i will post the source to the scripts/files section of ssc.com
Steve.
-
the only real issue with this is you can't/don't get the prompt string, so the parm name comes through, which often is in an ugly form (e.g. myParm1).
Steve.
-
Brilliant. Mind you I haven't worked with external assemblies as yet, but there has to be a first time I suppose!
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply