This is in SSRS 2008.
I've created a report with a tablix, embedded in the tablix there is a subreport. This subreport contains a lot of information (and I mean a lot – it takes more than 45 sec to load it).
I don’t want to show it, or to be more precise – to process/load the data when the report initially runs. Note that I dont want to just not display it - because then all the data is still processed at initial load time.
Instead, I only want the subreport to be processed (and the data pulled down), individually, when I display it (e.g. clicking a + sign to toggle it, or any other option such as clicking an image/ link, while staying in the same report). I also don’t want to open the subreport in a different tab or something like that....
Does anyone know a solution? Maybe there is an onLoad method, dynamic subreport or something like that?
I tried looking into the DataElementOutput attribute, but that's readOnly... anything else?
Before you jump through a lot of hoops to implement a workaround, have you analyzed the execution plan for the query which is delivers the data for the subreport? If you haven't, it's worth it to see if performance can be improved by adding a covering index which will help the query optimizer to deliver the data quickly.
Hope this helps,
Bill
So, as it turns out, the problem was in fact because I had the subreport repeated for each row in the parent report. Thus, the subreport was called numerous times...
And according to MS, there is no way to dynamically process individual subreports. Had to solve this issue by splitting out the subreport (at least the data-heavy parts) to a seperate page. :(
Related
I have a detail report with interactive sorting on the headers.
After the report is refreshed, the user would like to highlight some rows of data that appear throughout the report in order to see if patterns are detectable.
Say, a vendor name that appears on multiple customer rows might indicate that they all shopped at the same vendor before their credit card was compromised. Highlighting that vendor name might make it easier to spot whether this is a problem vendor. They won't know what they want to highlight until they start perusing the data, so a run-time parameter won't work.
In the past I used BusinessObjects which had a control that could be used to trigger alerts (formatting changes).
Is there a way to hack such a thing in SSRS?
Is there a way to hack such a thing in SSRS? No.
But, if the report user wants to export the report to Excel, then they can do whatever they would like to that spreadsheet afterward. They just need to know that any changes will not be written back to a data store any where as a result of that.
SSRS is purely for reporting data, not altering it, or annotating it. Changing the report output in Report Manager is not possible, either.
If you need to be able to highlight data in a report at run time, you can do that via a combination of properties and expressions in the RDL. Your business users would need to tell you what the rules for that are, then you can make the changes in what ever dev tool you are using to create reports.
I hope this clarifies some things for you.
Add a parameter that is populated with Vendor names.
Then in your rows, right click and go to TextBox Properties. Then click the Fill tab on the left and next to Fill Color press the fx button to add code:
=IIF(Parameters!VendorName.Label = Fields!VendorName.Value, "OrangeRed", "White")
This will highlight the cell OrangeRed if the VendorName in this row matches the one selected in the parameter.
I've seen websites explain how to use a tablix to list possible parameters for a report (another tablix) to simulate slicers. This technique relies on passing parameters and the report being refreshed.
The issue is, this is slow for where I want to use it. I am wondering if there is a way to load all the data for my report and then use a similar technique to create a slicer to limit the data using the filter on the dataset.
Another option I thought about was simply hiding the rows that didn't match what was selected in the "slicer".
A good way to speed up the processing time is to use caching. Go to "Manage Processing Options" in your report manager (or SharePoint, depending on what you're using). Set it to use cached data. Play around with the duration and cache refresh schedule settings to suit your situation.
You may also benefit from applying your parameters as Dataset filters as opposed to passing them into the query. This can help ensure that a cached version of the report will be available. It really depends on how big the dataset is and how many combinations of parameters you're trying to allow.
When a user hits my report I require they select a parameter to continue. What I would like to do is explain to the user, before they have selected an option, a little about the parameter options. It is fairly straight forward in the report below, however I have others that are much more complex.
Currently, the user has to select options then view the report; at which time an explanation of the parameters is available as part of the report. To me, it seems silly that a user would have to pick something 'blindly' just to get an understanding of how that parameter will impact the results.
I realize that appropriate parameter naming goes a long way, and we do our best to make that happen. We have a few situations where a sentence or two would go a long way in clarifying something before a user runs a report.
I have also used default parameters in the past to get the report to fully load when they first hit the page but that is not the solution I am looking for here.
Thanks in advance for your help!
Not possible to do via any provided functionality. The only way you're going to get this is if you use custom CSS sheets when accessing the report (either as a URL querystring parameter, or replacing the default stylesheets), or otherwise creating your own report page(s) to house your reports instead of Report Manager.
In SSRS 2008 R2, I was under the impression that a drill down to a sub-report would query the data on-demand.
This isn't the case when my report gets rendered.
Specifically, I have a Tablix that initially loads rows grouped by Person.
When someone clicks the drilldown icon on that Person, a subreport displays some more data pertinent to that Person.
The problem here is that every subreport is being loaded initially when the main report is being rendered. This takes forever to load. But if I remove the subreport, just for testing purposes, the report loads almost instantly.
I've tried setting the visibility of the subreport to Hide initially, then Show when the user drills down, but it didn't change anything.
I read a similar question on stackoverflow, but the answer was to use Drill-Throughs instead.
This unfortunately isn't an option in my case.
Any suggestions?
The only way to defer the data loading is to actually use a new report with and access it via Drill-Through method. This is the way to product work, and is the way inteded by Microsoft.
You can either optimize your stored procedure, limit the number of results per page or use drill-through.
I have report with some messages, and I would like to know is there a way for RS to have checkbox or link which will, when clicked mark message as read, or in other words, inserts/updates isRead column for that id?
Is this even possible?
Is it possible? Yes. Is it easy? Not a easy as most things in SSRS. Will it be elegant? Probably not.
You could create a check box icon which would link back to the report or some other action on the server. This would need to be set to handle a parameter indicating the checkbox clicked. Build a stored proc or other mechanism in the report to catch these clicks and make your column changes.
The biggest problem with this approach would be that, by default, the entire report would need to rerun and reload. You might be able to get something working that keep this smaller, but I'm not sure how.
My advice: don't do it. SSRS isn't designed to support this sort of interactivity with the data source. You'll be fighting against the tool. Look for another interface for this.