Executing an SSRS 2012 report cause the browser not to respond - reporting-services

I am using Dynamics CRM 2013 on premise.
I have built all the reports based on stored procedures in SSRS.
one report however, that has no issue with execution definitions, permissions or what ever,
once executed causes to browser to crash (any browser, i tried FF, Chrome, IE9 and up, )
it seems the problem is not a report execution problem but a report rendering problem for this specific report.
I cannot cache the report or make a snapshot of it, as the values of the reports also depends on the user running the report (among other parameters user-defined) and each user should get a different result. - i have more than 400 users.
I have tried searching for any one who had face this kind of issue and reported on it but failed. hence decided to post this question my self.
if anyone has any idea, please share.
thanks

Have you enabled tracing/logging in SSRS? http://msdn.microsoft.com/en-us/library/ms156500.aspx
You might turn on verbose logging while trying to run the report to see if you can get more helpful information.
If you write code, you can write a .NET application that calls the SSRS web services to render the report. Doing that will help you know for certain whether it's a browser rendering issue since you can get back the report as a byte array and save it to disk as Word, PDF, etc.

Related

How to find report execution log for visual studio preview of report

I am working on an existing SSRS report. It works when viewed in a browser from the report server (~ 30 seconds load), but loads for quite a while in visual studio preview (~ 10 minutes). The queries themselves are fast, so something about the report specifically is causing the slowdown.
As for what I have tried so far, I tried deleting the cached .data file (no fix), deploying the report (works fine when deployed), recreating the data sources, as well as attempting to avoid bad query plans from parameter sniffing (see Fast query runs slow in SSRS). None of these fix the problem. The problem only happens specifically when using local preview.
Many articles describe viewing the execution log to figure out what stage the report is taking so much time in (query, data processing, rendering). I would like to do this so I can narrow down the cause, but it works fine on the report server, just not on the local preview. How can I get the equivalent execution log when running local preview, given there is no report database?
I suspect that because forcing the query plans to recompile doesn't solve the problem, and because the report works fine with the same query against the same server when deployed, that the actual problem might be some weird rendering bug. I have heard this can happen with certain pagination settings, but I want to confirm what general area this problem is in.

Strange issue in SSRS 2016. I am unable to select parameters or run the report intermittently, it works fine most of the time

I am having a strange issue with SSRS 2016. We setup a new server and uploaded some reports, the reports ran fine for few days. The issue is, randomly the report doesnt run, When I load the report page, the parameters appear blank and I am unable to select any parameters. If I try to run and click the view reports button, nothing happens. After few mins/hours, it automatically resolves.
We have contacted MS support and could not get anything to get this resolved
Has Anybody faced a similar issue ?
This does not constitute an answer but it won't fit in a comment!
Does this affect more than one report?
If more than one, do they all fail at the same time or will one work and another not when you try to run the at the same time?
If the situation is "all fail" or "all work" at any single point in time then try adding a new report with no parameters.
If this attempts to run when other reports fail then it sounds like the datasource cannot be resolved or a timeout connecting to the database.
If your parameters are populated by querying the database the report will 'hang' until it can complete the queries to populate the parameters so by running a parameter-less report you should see an error instead.
Try running a trace on the database server to see if you can see the queries being run at all.
A bit vague I know but it might help you understand where the problem lies a little better.

Moving SSRS Report with parameters to Dynamics CRM 2013

Good morning, All.
First let me start off by saying that I'm extremely new at CRM and even after reading umpteen million articles, whitepapers, and blog entries, I still feel completely lost.
I have an instance of Dynamics CRM 2013 On Premise that I'm trying to write custom reports for. Before I realized that all reports had to be done inside of BIDS, I wrote out a beautiful custom Quote inside of SSRS itself. I made sure to use the Filtered Views in my query to the database, and the structure of the query seems sound, but I can't seem to upload the .rdl file into CRM.
I get the error:
Reporting Error
Error occurred while setting the data source for the report
I have two questions:
How do I move this report into CRM without having to fully recreate it in BIDS?
How do I pass the Quote ID from CRM to this report query?
Thanks in advance for all of your help.
Edit: Added Error Message
You Should be able to upload the RDL directly to CRM...
Try creating a really basic report with the same data source and something along the lines of "select top 10 from filteredincident" and upload it.
If it works then you know it's something with your query.
CRM is notorious for giving error messages that don't have enough information, or are at worst misleading. I've seen this error when I accidentally used non filtered tables and a autofilter parameter that was incorrect.
Also take a look at the SSRS server that CRM talks to, if it's misconfigured that may cause an issue as well. You may want to try uploading your report to SSRS and run it from there to ensure that SSRS is working correctly.

SSAS Tabular - Data is stale

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.

Reporting Services 2005 - Printing Graph - An error occurred during printing. (0x80004005)

I am trying to print a report that contains a bar graph using the report viewer, but running into an error. My reporting server is running SQL Server 2005 Reporting Services SP3 on Windows Server 2003 SP2.
Here are some steps that will reproduce the problem (at least for me)...
On a clean machine, I open up the
report, and it displays fine.
I then click the print button, and I
am prompted to install the
RSClientPrint ActiveX control. The
control downloads and installs fine.
I then click the print button again,
and the print dialog appears.
I select a printer, and click "OK".
A message box appears that has the
following text (including the
spelling error)...
An error occured during printing.
(0x80004005)
Any other report I try to print works fine. The only difference between this report and the other ones is that it contains a bar graph. If I remove the graph from the report, redeploy it, and then re-run it, it prints without getting that error.
As far as I know, it is not isolated to a specific machine. It happens to every customer I have talked to, and a variety of machines here in the office.
Has anyone seen anything like this? I have seen similar posts on the web suggesting to uninstall video drivers on the reporting server (thinking the GDI dlls have become corrupt ), install service packs, etc. I have tried every suggestion, but haven't found a good solution yet.
Thanks.
I ended up having to use a paid Microsoft incident on this, but it is resolved now. The issue was that I had a matrix in my report that had dynamic columns. Depending on exactly which date range you picked, the report could have n number of columns. In my case, when a date range was chosen that produced three or more of these dynamic columns, it would cause the matrix to become too large and run outside of the margins of the report.
The report would run and display fine with the matrix being too large, but the incredibly non-descriptive error would display whenever the report was printed or exported.
I resolved the issue by reducing the size of other columns and the overall font size in the report. This prevents the matrix from running off the page in the case of date ranges that produce three dynamic columns. It doesn't solve it in the general case (four or more columns will make it fail), but is good enough for my current purposes.
Microsoft didn't have a fix for the general case (such as a way to make the matrix fixed width).
I figured I should answer this in case anyone else runs across it.
-David