I have a report that uses parameters. The default parameters are defaulted to contain all available values, so by default the report the contains all possible data.
I want the user to then be able to deselect some of the values in the parameters, and to refresh the charts in the report, so they can drill down to the data that interests them.
But each time the report is refreshed, it runs the query again, slowing down the process.
Is there a way to allow the user to filter the data in the charts, without re-running the query?
I did find this, but it seems that he also didn't get a solution, or I didn't understand how the solution would work.
http://social.msdn.microsoft.com/Forums/en-US/0f905bdb-b8f2-4d9d-ac5b-e85d2f94f0cf/textbox-action-to-filter-existing-dataset-rather-than-rerun-query
To keep the query from running again, two high level steps must happen:
1) Make sure that your filters(parameters) are not included in the query. The query needs to be identical, no matter what the user has selected for a filter. This is done by moving the filters into the report. You can set them up as the filter on the tablix or on the row groups that are displaying the data.
2) Set up caching for the dataset. The easiest way to do this is by pulling the data set out of the report and create a "Shared Dataset." when you upload that to SSRS, define the dataset caching: maybe set it to last an hour. Connect the report to the shared dataset as well.
The full details of this can fill an article, such as http://www.mssqltips.com/sqlservertip/1919/how-to-enable-caching-in-sql-server-reporting-services-ssrs/ (for an old version of SSRS, but these concepts haven't changed much.)
Related
I have a report that is a form per order number selected prior to running report. I want to make it so that you can select multiple order_nos from a list (populated by a query that runs first). Right now, it throws an error saying ANY or ALL must be used. I think it is trying to use both order_nos as the parameter for the report. I want it to create the report using just one of the order_nos at a time, and just replicate the report several times. Is this possible?
The attached photo shows what I tried to do and the error thrown.
Error
If you want to create completely separate outputs then you will need to do this by creating a data driven subscription for your report.
The subscription will execute your report iteratively for each record produced in a preset master query that you create.
Each record in your master query should return all the order no's you wish to execute the report for.
However, if the report needs to remain interactive, and the order no's is only decided at runtime. Then i suggest you keep your report as is. Put a grouping on your tablix based on order no then apply a page break per group instance.
This will produce a single report output with each order no appearing on a different page.
As said above if you want a completely separate output (multiple excel/pdf file outputs) then you will need to use a data driven subscription.
If you need detailed steps on how to do either of the above then just let me know here and i can include steps.
I have an ssrs report that uses a Shared Dataset to extract a maximum datetime value that I want to use for multiple reports. I have created a shared dataset called MaxSnapshotDateTime.rsd that uses the query:
select max(snapshot_DT) as snapshot_DT from dbo.SystemLog (nolock) where sync= 1
My report dataset Snapshotdatetime uses the shared dataset. And my parameter #snapshotdatetime takes available and default values from the Snapshotdatetime dataset. I want to be able to use this #snapshotdatetime parameter for embedded datasets.
The #snapshotdatetime parameter is the first in the list of parameters. And the Snapshotdatetime dataset is the first in the list of datasets.
When I preview the report in SSDT it displays correctly initially. But once I select View Report the snapshotdatetime parameter displays as a dropdown with "Select a Value" as the default value and my snapshot datetime available in the dropdown.
If I set my available values for the parameter to be None then I get different behaviour: the parameter appears correctly but it is not available for other dataset queries.
Unfortunately I don't have sufficient permissions for a trace. And I have been unable to replicate with another source. Can anyone shed some light on what is happening when View Report is being clicked?
I am taking a wild guess here, but I have faced such issue before and have done lot of head-scratching. Turns out there is a rdl.data file in the solution where the rdl file resides(and it gets created automatically). This is the cache file for the report. When you "Preview" a report, the data and design for the report is fetched from this cache file, not the actual dataset. Hence there are chances it might be stale.
If you really want to see the report's output, instead of previewing it, try running the report from solution. That would be much more reliable.
Hope it helps you.
So, I have my report written and all is well. However now I have deployed to my live environment I have a problem; when the report is initially opened it runs all the dataset queries, as I have a large database the report is taking an age to display.
Is there a way to prevent all queries running when the report is initially opened? Would like to run just a single dataset query the populates my first parameter, so the user can begin to filter the data before selecting "View Report" to run the main dataset query with the parameters applied rather than getting everything the instant the report is opened?
I have tried setting default values in the parameters to reduce the initial data load but this seems to have confused the users, so think a blank report with nothing selected in the parameters to start with would be better.
Thanks
FTD
I assume you have some form of following.
QueryLookupState -- Used to fill dropdownlist etc.
QueryLookupCity -- Used to fill dropdownlist etc.
QueryMain , your main query which uses parameters from above.
You gave default parameters to your report therefore SSRS is using that defaults and running your main query to generate report. Change your main query and default parameters so that your main query bring empty result or main query needs parameters from lookups.
You can look following question and answer for same problem. You need at least one non-default parameter, otherwise SSRS will execute your report when it first opened.
I've been trying to get around this issue, and was hoping someone here might have paced the same problem.
My SSRS report has some default parameters that are set dynamically. What is happening is that when a report page is first opened (these reports are running from a custom web app), the 'main' report sproc is fired once, just to grab those 2-3 dynamic parameters, even though no other data from that sproc is displayed at this time (if this seems like overkill, it is...I inherited these reports from a former coworker who designed them). So, since there are 2-3 dynamic parameters, the report was designed to get these default values from a query. So, by the time the report is finally run by the user, the main sproc (just call it "report_getReportData" for simplicity) will have ran about 3-4 times already before it's ever rendered to the page.
What I did was, within the report_getReportData sproc, before doing my select * statement to display all the report data, I created a physical table to hold the 2-3 default values, and I created a new dataset in the report to just run a new sproc that just selects the value from this physical table, nothing else, so the result is the getReportData sproc only fires once, and my new sproc, let's call it 'report_getTwoParameters' fires once for each parameter, but the time cost is negligible since is just does one quick select statement.
This solved the issue of the overall report performance, but since there is now a physical table involved (report_getReportData returns data from a temp table), we face the issue of multiple users not being able to run this report simultaneously. So I guess my post has two questions:
1) Is there even a way to get around the main issue of having the report have to run report_getReportData just to set the 2-3 parameters - like maybe "multicast" the result set returned from the sproc into a couple different datasets or something?
2) If we decide to keep my solution of using the physical table, would anyone have any alternate solutions to this, in order for users to be able to run the report simultaneously but avoid bumping into this same physical table?
I have a report working well where I extract the number of logins per user. Each login takes up one row on the report.
I have date parameters and my DB goes back a year. However it seems the report will only show 40/50 rows despite a report expecting to deliver, say, 250 for the amount of times I logged in.
Is there some setting in reporting services that limits the number of rows delivered. Can't find it anywhere..
Thanks.
The answer to your question: nope, as far as I know there's no real equivalent of SQL's TOP 50 statement in SSRS itself.
Some things that come to mind that may be causing your symptoms / can be investigated:
What happens if you run the query for the dataset in SSMS? Be sure to fill in the exact parameters the report's using (if any).
Run the query as a test from SSRS designer. If you're using Visual Studio: right-click the dataset and hit "Query...", then hit the red exclamation mark and fill in any parameters if needed.
Try putting a CountDistinct call (on your dataset) in a textbox somehwere in the report, by itself.
Check the filtering and grouping on your tablixes, perhaps even by looking at the XML source code for the RDL.
Show the parameters in textboxes (oldskool printf debugging! :D) to make sure they're what you expect them to be when the report's run on the Report Server. If they're not: try deleting the report on the server and re-deploying it.
Have a look at the ExecutionLog2 View in the ReportServer database, specifically the Number of Rows returned.
As mentioned in the comments by Atilla: You may also monitor exact SQL SSRS sends to server using SQL Server Profiler.