I set several parameters for a report created in SSDT (SQL Server Data Tools).
How can I run the report on all available parameter value and form a comprehensive
report with each case per session?
Thanks a lot.
E.g. a report called 'data growth' with parameters #database and #tablename. A serial of available names for these two parameters. I would like to compile the report with all cases.
You have two options.
1.
Manually include an additional All option into your parameter selections, either by adding a value in the menus or unioning the value if your parameter options are data driven, and set the source query to return all results when selected.
2.
Change your parameter to a multi-value parameter and change your source query to use where database in(#database) which will enable all combinations of your parameter to be selected, including all.
Related
My quality engineers have asked me to create a report based on a document that they fill out manually. At first glance, it appeared to be an easy enough request. It has been anything but easy. This report shows the results of two inspections and I have a parameter where the user selects one inspection or the other. As it stands now, this report runs just fine when selecting one inspection, but I am anticipating a request to be able to run the reports for both inspections at the same time. And, that's where I run into trouble.
The problem is that I have a text box in the header that is referencing a value from a table in the report that identifies the inspection. When I set the parameter to a multi-value parameter and select all, the report only displays one of the inspections across the entire report. Is it possible to have the user select both inspections but have the report run them separately? I have one dataset for the table and a column in that table that identifies the inspection. I have tried the multi-value parameter and I have tried using the filter option in the dataset properties, but I get the same result.
The easiest way to do this might be to create a new master report and use your current report as a sub-report. It's fairly simple.
Here's the basic steps...
Make a copy of your current report and rename it (say sub_InspectionReport)
Change this report so the the inspection parameter is NOT multi-valued
Create a new report and add your parameter(s) the same as you setup for your original report, This time make sure your Inspection parameter (e.g. pInspection) IS multi-valued.
Create a dataset (dsInspectionIDs) that returns a list of the selected inspection values from the pInspection parameter. The query could be something simple like
SELECT InspectionID FROM myInspectionTable WHERE InpectionID IN (#pInspection)
Note: #pInspection is the name of your report parameter, it is case sensitive.
Now add a table to the report and, as a simple, test, se the dataset of the table to your daatset dsInspectionIDs. Set the first column to show the only available field (in this example InspectionID).
Run the report and test the output using different inspection parameter selections. The table should match what you have selected...
We're almost there...
Now in one of the table cells (but not in the header) , right-click and select "Insert / Subreport". Now right-click the sub-report placeholder and set the sub report to be the copy of the original report we made at the start (sub_InspectionReport in this example). Now, still in the sub-report properties, go to the parameters tab and set the Inspection parameter to the the InspectionID field.
Now when you run the report, you will get your sub-report run once for each selected parameter value with that parameter passed to the sub-report.
Hope that makes sense, I'm not near my PC so I can't provide a sample with images at the moment.
I'm seeing some weird behavior I can't quite figure out. I have a report with a bunch of parameters, none of them are cascading. A handful of the parameters are set to allow multi-select and the available/default values are retrieved from data sets that used stored procedures.
When I load a report every data set executes, which I expect. However, if I change a parameter value, such as the date for the date parameter, every data set executes again. Why is this?
What's compounding the situation is I have 2 copies of each parameter (Param1, Param1_Internal, Param2, Param2_Internal, etc.). I have it setup like that for formula's I'm using in the report to determine if the user selected 'Select All' for the multi-select parameters. So for example I'll have Param1 and Param1_Internal set from data set 1, Param2 and Param2_Internal set from data set 2. When I change an unrelated parameter data set 1 will execute twice, and then data set 2 executes twice.
Any suggestions to:
Get these data sets to run once each, even though one data set feeds available values for 2 parameters?
Stop the data sets from running every time I change an unrelated parameter?
I am currently on SQL Server 2016.
Thanks
Edit
So, I found the answer to part of my question. In some cases I am using an expression as the parameter value in the data set that calls my stored procedure. It looks like when you do this, SSRS will execute that data set every time you change any parameter value. I still am hoping someone will have advice on how to have a dataset run once in a situation where I have 2 parameters using it for default/available values.
You can cache data set results if they are in a shared dataset stored on the SSRS server. This way the first time you run it will execute the query, then the second will just pull from the cache:
https://learn.microsoft.com/en-us/sql/reporting-services/work-with-shared-datasets-web-portal#caching
Use with caution though, as if the backing values of your parameters change often you could get inconsistent results with your reporting.
You can stop the refresh on parameter change by making sure the below is set within the parameter properties:
I am trying to restrict what users can view based on the branch that they work in. I have it working on my main report but I want to pass the branch parameter from my main report to a drillthrough subreport. How can I do this in Report Builder 3.0? Thank you.
You can pass the parameter via the url.
Example:
http://myrshost/ReportServer?/AdventureWorks 2008R2/Employee_Sales_Summary_2008R2&ReportMonth=3&ReportYear=2008
Here we're passing the report parameter ReportMonth the value 3 and ReportYear with 2008
An alternative to using a URL, you'd need the same parameters in both reports.
Go to the properties of where you want the drill-through to occur.
Go to Action
Select 'Go to Report', specify the report directory (this can be flat files or via the report server). Think this can also be a URL but I am not certain.
Select 'Add'. In the Name field, you want to put the parameter name of the parameter in the drill-through report, in the 'Value' field you want to enter the parameter of the report that you're currently in.
If you don't want the user changing this parameter, in the drill-through report, you can simply hide this parameter in the drill-through report.
This is by far the easiest way of doing what you require I believe. Hope this helps if you're still struggling.
We have a report in SSRS that has drop down list parameters that are fed by a shared datasource and query.
If I use ReportViewer to view the report these work as expected.
However, I'm also using the SSRS web service to pull out the parameters and the available values. In this instance when drop downs are moved from a manually entered list to a query the available values list is empty.
I'm assuming the problem is because the web services simply gropes the RDL file and does not execute the queries attached to the parameters.
My question is, is there any way to have it do this or to get the available values?
After reading MSDN it seems the answer is to call GetReportParameters() and set ForRendering to true:
If ForRendering has a value of false, the parameter meta data returned represents the parameter data that is currently associated with the specified report. If any parameters values are based on a query and you are interested in returning the query-based parameters valid values list, you need to set ForRendering to true, In addition, for query based parameters, you need to ensure that you have passed in all of the credential information required to return the query parameters.
I have a report table with all the combinations of dimensions as generated by the parameters set by the user. Each row contains 1 combination and a link to another report with charts. How do I pass that combination of parameters/dimensions to that other report?
In the row, I have a textbox Action which has a "Go to report" hyperlink. In the main report. I see an option "Use these parameters to run the report" which I fill out with the similarly named parameters on both reports.
On the linked report, the user should not have to pick options from that set of parameters again. Setting the report parameters to internal, hidden with blank prompt (a single space), visible with blank prompt (a single space), and putting a (Null) default value still gives: "The report parameter is read-only and cannot be modified. (rsReadOnlyReportParameter)"
What gives? How should the parameters be configured on either side so the combination of parameters are passed to the linked report?
If it is truly a linked report, then you should be able to hide the parameter in the linked report properties.
If it's a drill through report (more likely), then just set the parameter to hidden in designer. Internal means it is not exposed at all:
Setting the Hidden and Internal
options provides different levels of
visibility. You can hide the parameter
on the parameter input area of the
published report, yet set values for
it on a report URL [My text: this is what drill through does] or in a
subscription definition. If you set a
parameter to Internal, it is not
exposed in any way except in the
report definition.
The real solution to the real problem probably lies somewhere else, but just recreating the report item from scratch instead of using the converted (from SSRS 2005 to SSRS 2008) report item solved the problem described above. The drillthrough report should have the parameter hidden.