I have used a 'Union' to combine two reports showing different dates. When I open the report on it's own it works fine with the two dates shown. However when I drill to the (union) report from another on the dashboard it only shows one date. Is there a dashboard filter that I may need to un apply or is there some other explanation!? I cannot seem to get the report to function as required from the drill.
Tough to answer - need more info. Some possibilities:
You're not really drilling to the report you think you are. You can learn a lot by looking at the log to see what's happening in the target report.
You may be passing values from the first report that exclude the date in the second report. Check your filters in the target report. Look at the generated WHERE clause in the log. Run the SQL directly against the database. Is the date still excluded?
You want to start by checking the physical SQL which is written to the nqquery.log. It can also be obtained by viewing the log in Answers directly. Another way is to go to Administration > Issue SQL, enable presentation server cache, set the debug level to 7, execute the SQL and click on the view log link. The Physical SQl can also be tested against the actual database, if that is where your data is coming from. Examining both - your Logical SQL and your Physical SQL can resolve a lot of minor issues, including this one.
Related
I have a stepped report that has 5 row groups. Each one uses an expression as the value to group on. The user selects a value for up to 5 different parameters and based on those parameters is how the report is grouped.
With certain combinations of parameters the report may take 2min + to run in the preview pane in Visual Studio. When I deploy the report to the SSRS server the same combinations of parameters runs in 10 seconds or less. Out of curiosity, I created a copy of the report and removed the expressions from each of the row groups and specified a field to group on. In that case it previews just as fast as when viewed on the server.
Anyone have any idea what may be going on here?
I'm currently using Visual Studio Enterprise Update 3.
I realize this is an older issue, but maybe this will be some help to you.
I am experiencing similar symptoms to what you have described and it comes down to using dynamic fields in grouping statements. Apparently, any other statement can use dynamic fields without issue, but groupings incur a huge performance hit.
This link outlines the symptoms and causes.
I don't know if it was in that particular link or not but I read something about how the ReportViewer control when it renders to HTML has a bug in it that only happens when the control is running under .Net 4.0 or higher. In .Net 3.5 the performance is pretty much the same as it is if you were to run the RDL in the Report Viewer application.
If you are able to do so, the quickest way to get the report viewer component to work is to have the application pool IIS is using to run under .Net 2.0 (or 3.5 if that option is there, since they're basically the same thing).
If your application uses .Net 4.0 or higher for other functionality, there isn't much I've been able to figure out, short of rewriting the report to remove dynamic references from groupings, but that significantly reduces the interactivity of the report (no expand/collapse options in table rows/columns).
For reference, I had a report, where the query took about 2 minutes to execute, and then rendered almost instantly afterwards if I loaded the RDL in SSRS. That same report rendered using the ReportViewer control in .Net 2.0 took about 2 min 30 sec to fully render. Using the exact same code, but changing the app pool to use .Net 4.0, the report has been "rendering" for roughly 15 minutes now and still hasn't come back.
First of all and a bit obvious, if you are running your report in a development machine it won't have the same computing power as a server. Even if you are running VS from the server it won't run as fast as a deployed report.
The cause -as you may notice- for the slow performance is the grouping expression. It seems your report is taking to long to process so check this article from a Technet post. I copied and pasted a paragraph below:
Many levels of nested and adjacent groups in a Tablix data region can
affect report processing performance. Consider both the level of
grouping, the number of group instances, and the use of aggregate
functions which require evaluating after group, filter, and sort
expressions are applied.
I recommend you try to perform the grouping in the datasource at SQL level, you can also pass parameters to the query to set the desired grouping there.
Let me know if this helps.
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.
I have a folder with around 15 reports in it, these are Report Server reports. To run each report individually will take a while, so I want them to run together. So, what I want to be able to do is somehow run all the reports in this folder, is this possible?
This is somewhat of an ambiguous question. Let me explain. What are you asking specifically?
Q: Can you run multiple reports at the same time?
A: Yes, and there are several ways to accomplish this.
1. You can use SQL agents
2. Use batch files with task scheduler
3. Use an SSIS package and use an agent to run them at specific times...etc...
Hopefully one of the reports does not depend on another and another thing that you have to take in to consideration is how hard you will be hitting the SSRS or SQL server. Running them all at one time may take longer than one at a time. depending on the bandwidth of the SQL Server and what tables are going to be locked up during each of these processes.
You might want to give a little more detail in your question...
I would recommend an SSIS package, especially as it also one of the options presented by #Michael that can email the Excel workbook too which you mentioned in an earlier comment.
The following resource covers quite well the execution and export of an SSRS report using SSIS, including code you will need as a starting point: Executing an SSRS Report from an SSIS Package.
You could save some time in coding the solution by using the following custom Task that can be integrated into SSIS: SSIS ReportGenerator Task.
There is one problem in your requirements though which is merging reports into one Excel workbook where I assume you want separate sheets for each report within the same workbook?
Reporting Services can use multiple worksheets (to divide a report up into pages a.k.a pagination) but only for a single report; it can't merge reports into one Excel file. This can be accomplished with custom code however. There's a somewhat basic example here: Merging workbooks into a master workbook with separate sheet for each file.
One way to run all the reports at once is to add subscription to all of them and set same subscription start time in all of the reports. what will happen is once the start time arrived all the reports will run simultaneously and will generate excel/pdf (any format specified) file at shared location.
Morning folks.
This problem is very isolated but very annoying. It only happens with one customer I do work for, and can happen when creating new datasets or amending existing ones, but doesnt happen every time.
So lets start with a new dataset. I right-click and Add Dataset, I give the dataset a name, select the data source and then select Stored Procedure. This is where the fun begins. I start to type the SP name and BOOM, Report Builder crashes. I know I can just pick off the list but in the case of this client, the list of SPs is massive, so starting to type the name narrows down the list.
This can also happen if I amended the name of an SP within an existing dataset.
It has to be something to do with configuration as this doesnt happen with any of my other customers. The only difference with this site is they use Citrix but I cant see how that would affect this.
So, Report Builder 3.0 connecting to a SQL Server 2008 R2 instance. Any suggestions?
Thanks in advance
It seems not the issue on SSRS side, please let the user connect the database and execute the SP directly to check the performance. It also can be some hardware or configuration issue on that client's machine. You can suggest him use Process Monitor to fetch some detail information.
I have a tabular model that I've processed and deployed.
I'm having a problem getting SSRS to reflect the newly deployed information. I have a shared Dataset accessing a shared Data Source. When I run the MDX in the query designer of the Dataset, the correct numbers are returned. When I run the report, however, the old numbers still show. I've tried deleting the .DATA file but it didn't help.
EDIT:
I've verified that the problem is in the SSAS database itself. I queried it with drillthrough from SSMS and saw that it is returning rows that aren't in the source views any more. They used to be, but no longer.
This almost seems to be some crazy caching issue. I've rebooted and dropped/redeployed the SSAS database and no luck.
Any thoughts?
I would suggest a few steps.
Ensure you are connecting to the correct tabular model.
Expand the tables in the tabular model, and right click one of the tables and click "Process". Check all the additional tables in the model.
Change "Process Default" to "Process Full" (Process default does not always work correctly)
Click Ok.
You should now see the model process table by table.
I would close and re-open the report.
Actually I would completely ignore the BIDS / Visual Studio Preview pane as it is riddled with bugs and inconsistencies and proves nothing (assuming your end users aren't using Visual Studio).
Instead I would deploy the report for each test run to a test environment / folder on the host server (Report Manager / SharePoint). As well as being a realistic and meaningful test, this has many advantages such as being able to leave multiple IE tabs open with various parameter combinations set, then just refresh them after a Deploy to retest.