I have a main report and 30 subreports under that report. I don't want to see all of the subs every time I call the main report, I only want to see the subreports that were selected in the application.
How do I only show selected subreports?
The comment from Martin K. is correct if you're only concerned about the display of the sub-reports. You can set the visibility property via an expression meaning it can also be controlled by the result set or a parameter.
However, the real issue is that even though the sub-reports are hidden they are still run. This is because SSRS retrieves all of the data for the report before it finalizes the rendering. There are a number of good options discussed in this TechNet posting. But basically it boils down to two options:
Parameters & WHERE clause filtering
You can set a hidden parameter on the sub-reports and modify the WHERE clause so that the SQL will not actually return any rows when the parameter isn't set to true. This won't stop the report rendering actions but it will stop the SQL commands from having much of an effect on the server.
Just setup a parameter on your sub-report named #ShowSubreport and use filtering similar to the following
WHERE #ShowSubReport=1
Report Definition Customization Extensions (RDCE)
I haven't actually used these but it sounds quite handy, but it isn't exactly simple or easy. Report definition customization extensions allow you to programatically alter a report definition file on the fly. It takes an RDL as input and outputs an altered RDL stream. You can read more about it in the MSDN article : What's New in Report Server Programmability
Related
I have many reports which use a set of the same report variables:
Is there any possibility not to insert them each time manually when creating a new report? Or may be there is a possibility to share these variables between reports as , for instance, DataSources?
Can be used for this purpose assemblies?
Based on your question it's seems you're looking for a subreport. Sub Report is a tool available in the toolbox in SSRS. It allows you to create a report that can in included in all your other reports without have to rebuild the structure.
Once you've created your report in the sub report properties just specify the report and include the parameters used for the report (if any) see below:
If that's not what you looking for, then maybe it's shared data sets you're looking for.
Let me know if it's something completely different and I may be able to provide alternative solutions.
Thanks
Gav
Assuming a fairly conventional SSRS 2012 report (in Visual Studio 2012) with a main report, a set of sub-reports, a shared dataset that is populated at the start of the report, and a shared datasource.
Is there any simple way within a sub-report's custom code (this is VBA, right?) to access the shared dataset, either to read or update records locally? (No updates back to the database itself.) I'm seeing hints out there that this is possible but no clear examples yet.
And if the above is possible, assuming that a call in the sub-report changed a record in the shared dataset, could that record change be displayed in the main report body?
Yes and No.
I think the overall concept would work but a few points won't.
I don't think you'd be able to use the report dataset with VBA. The code won't have access to the report's datasource directly. You'd probably need to use ADO to access the db from VB.
The only way to see the updated data would be to refresh the report - either manually or automatically on the timer.
I don't see how the subreport is going to figure out what to update the value to. You might have some idea that I'm not seeing right now.
The easier way I see this working would be to use parameters that default to NULL. Then select the row to update with one parameter and the value with another. Then have an UPDATE in your main query that only runs if your parameters are populated.
I'm having an Inventory cube with a dimension of "DimForecast". Related report is created by SSRS report builder and published to sharepoint.
End user wants to have what-if analysis so that they could edit Forecast Value directly from user interface (currently, ssrs report) and see how it will influence inventory stock.
Also, once their browser's session is expired (e.g. refresh webpage), all data will be converted back to original ones, which are pulled from Data Warehouse to cube.
Is there any possible work around for this functionality? "Power view" can do similar job but it's only available in Excel. However, for this case we have to use report builder, which is designed neither to user-interaction nor to session-based processing.
The only possible input in the scenario you describe is a parameter e.g. "Forecast Value". You would need to code SSRS expressions to accept the "Forecast Value" parameter and use it in SSRS Expressions to derive the returned data on the report.
A default value of 0 for the "Forecast Value" parameter could be used to effectively "reset" the data back to the original values.
It seems to be stating the obvious, but SSRS in SharePoint seems a really poor choice for a "what if analysis" requirement.
I have used a Guage as a clock. It is set to auto-refresh for every 3 sec.
It is running properly, but whole report is refreshing, reloading. So cant get a feel of a clock.
So I tried to use this (Clock) report as a sub-report in another report (say main report) which is not set to auto-refresh.
I am not getting why my sub-report is not auto-refreshed in main report.
Ideas & Hints are welcome!
I've never used the auto-refresh property of a report but I would guess that since it is a report-level property what you're expecting to happen won't work. In order for only the subreport part of the report to refresh it would effectively need to be a frame or iframe (using HTML as a reference). SSRS does not render this way and so your subreport isn't going to autorefresh. It renders the subreport and shows it in the subreport control and moves on.
I'm not really sure how you could have a dynamically updating element in a report using the standard controls. It would need javascript or some kind of other client-side scripting language that gets processed in order to keep functioning and even then it would only work when rendered to HTML.
Basically I don't think this is possible without a third party add-on, and I don't know of one that allows dynamic refreshing of individual report elements without refreshing the whole report.
If you can program in .NET you could write your own custom control for SSRS. This is effectively a third party addon you would create yourself. You could create a clock control and even give it properties to make it customizable. If you're going to use it in reports that you deploy to a report server you'll need enough access to that server to deploy the control assembly to the necessary location. See these MSDN pages for more info:
Creating a Custom Report Item
Jazz Up Your Data Using Custom Report Items In SQL Server Reporting Services
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.