I'm having some issues with a report deployed to an SSRS 2016 server.
When the report is run in IE, Edge or previewed in VS it returns the correct result (some sales data for the current month), but when the same report is run in Chrome it returns values for the whole year.
I've searched for thoroughly for a resolution but was unable to find anything. I did find a few posts here and elsewhere regarding compatability issues between Chrome and SSRS 2016, but the resolutions (using various Chrome extensions), did not work. Using an extension is not really the solution that I want, as I'm more concerned about users viewing reports in Chrome and seeing incorrect results.
Additional info:
+This is a report I have inherited and did not design.
+Report has a number of parameters, some hidden, some not.
+Report contains 18 datasets.
+There are some textboxes with actions in the report, each of which execute the report with different parameters (eg last quarter, YTD).
+When certain actions are executed, the report returns the below error. This only happens when using Chrome.
An error has occurred during report processing. (rsProcessingAborted)
Cannot read the next data row for the dataset ConversionRates. >(rsErrorReadingNextDataRow)
For more information about this error navigate to the report server on the >local server machine, or enable remote errors
+The dataset described in the above error is not the same every time the report is run.
What I've tried already:
+Various Chrome extensions (more as a test than a solution), these made no difference.
+Searching this site / Google for suggestions but to no avail.
What I would like to achieve:
I would like to know how I can ensure that the correct results can be
returned in Chrome for any user, without having to perform any action
on each user's machine.
I realize this is not much to go on, but I'm hoping someone else has encountered the same error. I suspect it's something to do with rendering in Chrome but I can't figure it out, so any suggestions at all would be greatly appreciated.
Thanks v much
Related
We have a process that generates around 20,000 PDFs using SSRS as the backend.
The mechanism used to generate these is the Report Execution 2005 API endpoint
We have just performed a run where occasionally a PDF would be generated missing some data, or the header or the body or the footer.
The break down of that was around 12,000 generated correctly, 1000 blank, 7000 data incorrect.
There doesn't seem to be a rhyme or reason for this, no pattern in the data or timings. In the logs we can see the following:
We log all parameters used to execute these reports in a DB, so using this we went and re-run that report with the same parameters and it ran fine. We then went and took 100 of the random errored ones, ran them manually and they all worked fine.
My only straw left to grasp at is there is some caching or SSRS deep issue that is causing this.
If anyone has seen something similar or has an opinion on where to check next, would be much appreciated.
We've been successfully using SSRS auto refresh (SQL Server 2008R2) on a variety of clients over the years and never had any problems. Various combinations of Chrome and IE on various OSs (windows XP, 7 and 10) have all been fine. We've just deployed a new report to run in full screen mode on TV screens, and it seems to be PARTIALLY refreshing. The Globals!ExecutionTime displays accurately, but new rows (INSERTs in the source data) in the report's tablix do not show up until the report is manually refreshed. Even more oddly, UPDATEs to the source data seem to make it through the auto refresh process. The problem only seems to occur on these particular clients.
We've set up a report history to help monitor this problem, and it works as expected. In fact it highlights the inconsistency, where newer information is captured in snapshots that were run earlier that the screen autorefresh.
The report execution logs are recording exactly the executions we'd expect to see. The data is just not making it onto the screen.
The report's processing options are:
Always run this report with the most recent data,
Do not cache temporary copies of this report
Any suggestions greatly appreciated :-)
Well we eventually resolved it. The problem turned out to be not exactly as described above. It seems to have been due to unusual combination of several cascading parameters, and a rapidly changing underlying dataset. What would happen, is that:
The SQL behind the cascading parameters would be executed on autorefresh in order to populate each parameter's default values.
During or shortly after this, the source data would change.
Next the final dataset SQL would be executed using the now out-of-date parameter values, and bring back the wrong results.
The solution was to remove four of the five cascading parameters from the report (and the underlying stored procedure). The stored procedure had initially been intended to be widely used and that was the reason for needing all the parameters. Turns out though that it was only used by the report, so as luck would have it we were able to simplify the process.
I have a set of SSRS reports developed in Visual Studio Data Tools that are used for several clients.
For one particular site, each report will work perfectly in 'Preview' mode in Visual Studio, however when I deploy them and attempt to run them in IE all of the parameters are disabled/greyed out. I also tried to put in a set of default parameters to see what would happen and when I click 'Run Report' I do not even get the 'Loading' image and the report is just blank.
I have checked the IE security settings and have reset them, and also added the report web page location in to trusted sites which unfortunately hasn't made a difference. One thing I have also noticed is that when I try to view Developer Tools in IE, it also just shows a blank white screen.
I've searched online and found a couple of old posts on various websites with a similar issue but none that were ever resolved, and now I am not sure how to proceed.
More info that might be useful:
The client are using IE 11, it is a terminal server style setup with around 8 or 9 users logged on.
The report I am testing with has 2 date parameters first, and two multi-valued parameters (I have tried other reports but with the same issue)
The client recently moved servers and the reports worked fine before, although it was a fresh install of the report so I don't believe there would be any old settings that could be causing it?
Any help greatly appreciated :)
In SSRS, report parameters can be inactive when the report is generated from a snapshot. Removing this option is as follows:
Navigate to the report in SSRS
"Manage" the report from the drop down.
Select "Processing Options" from the left menu
Is "Render this report from a report snapshot" selected? If so, switch
to "Always run this report with the most recent data" option.
Run the report to determine if parameters are now active.
If this fixes your issue, you may need to switch from the snapshot option to the Scheduled Cache option available under the left menu link "Cache Refresh Options"
For one particular site, each report will work perfectly in 'Preview' mode in Visual Studio, however when I deploy them and attempt to run them in IE all of the parameters are disabled/greyed out.
If that is the case, and a previous version of the report was already on the SSRS report server, what you can do is delete the report, and upload it again. There is some kind of cache for the parameters, that causes that if you modify the order of them, some get disabled, and the only way I have found to get rid of it is to delete the old report from the server.
For me this worked:
Open IE
Go to Settings->Compatibility View Settings
Add the URL of your report server.
You could be experiencing an old bug which was reported a long time ago in a connect item:
SSRS Weird Parameters Order Bug (parameter grayed out)
The official Microsoft answer on this subject is:
Currently this behavior is per design. However we will consider this
behavior improvement in a future release of reporting services The
only workaround at this point is to change the order of the
parameters.
Are the parameters on the RDL file set to visible, like below:
Just going to add this as an answer, because it solved the issue for me;
Delete the report on the server & deploy again.
What happens is that you completely remove the report and thus also its parameters. When you deploy a report its parameters their default values do not get overwritten in case it didn't have a default the first time you deployed.
I'm using SSRS to manage our reporting needs. I've built the first report in BIDS and have deployed it to the report server. I am able to run the report using the (browser-based) Report Manager.
For some reason, I am unable to display the report using the WinForms-based Report Viewer component. The parameters are displayed correctly, but when I click "View Report" I get:
The report execution ..... has expired or cannot be found. (rsExecutionNotFound)
As per this question, I suspected that it could be a timeout issue. But the report runs very quickly and the issue does not disappear when I set the timeout options (both at report and server level) to "Do not timeout report".
I've read elsewhere that the issue can be caused by a difference in timezone settings between Report Server and SQL Server. This doesn't seem to explain my issue however, as I am still able to generate reports using the browser-based interface.
What could cause my report to fail solely in the ReportViewer component?
UPDATE - As suggested by #lrb, I had a look at the logs. The error in the Report Viewer component seems to correlate with the following:
library!ReportServer_0-9!2dcc!07/23/2014-17:45:14:: e ERROR: Throwing Microsoft.ReportingServices.Diagnostics.Utilities.ExecutionNotFoundException: , Microsoft.ReportingServices.Diagnostics.Utilities.ExecutionNotFoundException: The report execution hcy3t555yc0rqp45rpovkz55 has expired or cannot be found.;
webserver!ReportServer_0-9!2dcc!07/23/2014-17:45:14:: e ERROR: Reporting Services error Microsoft.ReportingServices.Diagnostics.Utilities.ExecutionNotFoundException: The report execution hcy3t555yc0rqp45rpovkz55 has expired or cannot be found.
at Microsoft.ReportingServices.WebServer.HttpClientRequest.InitForRequest(CatalogItemContext context, UserContext userCtx)
at Microsoft.ReportingServices.WebServer.ReportServiceHttpHandler.RenderReport()
at Microsoft.ReportingServices.WebServer.ReportServiceHttpHandler.DoStreamedOperation(StreamedOperation operation)
at Microsoft.ReportingServices.WebServer.ReportServiceHttpHandler.RenderPageContent()
at Microsoft.ReportingServices.WebServer.ReportServiceHttpHandler.RenderPage()
To my (admittedly inexperienced) eyes, this isn't really any more informative than what I was seeing in the Report Viewer; i.e. "The report execution has expired or cannot be found" Maybe I'm missing something though?
Moving from design-time report selection (using the smart tag) to run-time selection (using the SOAP interface) seems to have resolved this issue.
My guess is that the reportViewer.RefreshReport(); call is responsible. This would suggest that Report Viewer will always try to grab an old version of the report, rather than requesting a new one. Since increasing the timeout didn't help at all I'm not sure why this behaviour would be useful, but I'd happily be corrected on this point.
First off I understand that it is a horrible idea to run extremely large/long running reports. I am aware that Microsoft has a rule of thumb stating that a SSRS report should take no longer than 30 seconds to execute. However sometimes gargantuan reports are a preferred evil due to external forces such complying with state laws.
At my place of employment, we have an asp.net (2.0) app that we have migrated from Crystal Reports to SSRS. Due to the large user base and complex reporting UI requirements we have a set of screens that accepts user inputted parameters and creates schedules to be run over night. Since the application supports multiple reporting frameworks we do not use the scheduling/snapshot facilities of SSRS. All of the reports in the system are generated by a scheduled console app which takes user entered parameters and generates the reports with the corresponding reporting solutions the reports were created with. In the case of SSRS reports, the console app generates the SSRS reports and exports them as PDFs via the SSRS web service API.
So far SSRS has been much easier to deal with than Crystal with the exception of a certain 25,000 page report that we have recently converted from crystal reports to SSRS. The SSRS server is a 64bit 2003 server with 32 gigs of ram running SSRS 2005. All of our smaller reports work fantastically, but we are having trouble with our larger reports such as this one. Unfortunately, we can't seem to generate the aforemention report through the web service API. The following error occurs roughly 30-35 minutes into the generation/export:
Exception Message: The underlying connection was closed: An unexpected error occurred on a receive.
The web service call is something I'm sure you all have seen before:
data = rs.Render(this.ReportPath, this.ExportFormat, null, deviceInfo,
selectedParameters, null, null, out encoding, out mimeType, out usedParameters,
out warnings, out streamIds);
The odd thing is that this report will run/render/export if the report is run directly on the reporting server using the report manager. The proc that produces the data for the report runs for about 5 minutes. The report renders in SSRS native format in the browser/viewer after about 12 minutes. Exporting to pdf through the browser/viewer in the report manager takes an additional 55 minutes. This works reliably and it produces a whopping 1.03gb pdf.
Here are some of the more obvious things I've tried to get the report working via the web service API:
set the HttpRuntime ExecutionTimeout
value to 3 hours on the report
server
disabled http keep alives on the report server
increased the script timeout on the report server
set the report to never time out on the server
set the report timeout to several hours on the client call
From the tweaks I have tried, I am fairly comfortable saying that any timeout issues have been eliminated.
Based off of my research of the error message, I believe that the web service API does not send chunked responses by default. This means that it tries to send all 1.3gb over the wire in one response. At a certain point, IIS throws in the towel. Unfortunately the API abstracts away web service configuration so I can't seem to find a way to enable response chunking.
Does anyone know of anyway to reduce/optimize the PDF export phase and or the size of the PDF without lowering the total page count?
Is there a way to turn on response chunking for SSRS?
Does anyone else have any other theories as to why this runs on the server but not through the API?
EDIT: After reading kcrumley's post I began to take a look at the average page size by taking file size / page count. Interestingly enough on smaller reports the math works out so that each page is roughly 5K. Interestingly, when the report gets larger this "average" increases. An 8000 page report for example is averaging over 40K/page. Very odd. I will also add that the number of records per page is set except for the last page in each grouping, so it's not a case where some pages have more records than another.
We narrowed down the large PDF exports from SSRS and found 2 main culprits
1) Unless images are JPG or PNG colour type 3, they are expanded to BMP's See here
2) Unless you configure SSRS to behave otherwise (not recommended), then SSRS will embed fonts or font subsets into the PDF, unless they are one of the 5 'standard' PDF fonts.
Although none of the standard fonts (other than Symbol I guess) are installed on most Windows OS's out of the box, we've found that if you use Times New Roman, Courier New, or Arial then forward and reverse font substitution will take place.
The easiest way to convert your RDL's is to view them as XML and search and replace the FontFamily tags.
If you have to use a non standard font, then, you can still minimize the damage:
Use as few fonts as you can. Search through the RDL XML to make sure there aren't any redundant fonts.
Use TTF fonts if you use different sizes of the font.
Try not to mix normal, bold and italic variants of the font, else it will be embedded multiple times.
Does anyone know of anyway to
reduce/optimize the PDF export phase
and or the size of the PDF without
lowering the total page count?
I have a few ideas and questions:
1. Is this a graphics-heavy report? If not, do you have tables that start out as text but are converted into a graphic by the SSRS PDF renderer (check if you can select the text in the PDF)? 41K per page might be more than it should be, or it might not, depending on how information-dense your report is. But we've had cases where we had minor issues with a report's layout, like having a table bleed into the page's margins, that resulted in the SSRS PDF renderer "throwing up its hands" and rendering the table as an image instead of as text. Obviously, the fewer graphics in your report, the smaller your file size will be.
2. Is there a way that you could easily break the report into pieces? E.g., if it's a 10-location report, where Location 1 is followed by Location 2, etc., on your final report, could you run the Location 1 portion independent of the Location 2 portion, etc.? If so, you could join the 10 sub-reports into one final PDF using PDFSharp after you've received them all. This leads to some difficulties with page numbering, but nothing insurmountable.
3. Does anyone else have any other
theories as to why this runs on the
server but not through the API?
My guess would be the sheer size of the report. I don't remember everything about what's an IIS setting and what's SSRS-specific, but there might be some overall IIS settings (maybe in Metabase.xml) that you would have to be updated to even allow that much data to pass through.
You could isolate the question of whether the time is the problem by taking one of your working reports and building in a long wait time in your stored procedures with WAITFOR (assuming SQL Server for your DBMS).
Not solutions, per se, but ideas. Hope it helps.
Obviously, its a huge report, in fact it's closer to a 1.3 GB database, than a report.
Have you thought of finding a way to split it into multiple pieces and then combine them together? (use one of several different ways to combine PDFs listed on this site.)