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
Related
A couple of weeks ago, our Access application suddenly began to fail mysteriously. Comboboxes on random forms would not fill with rows when recordsources were set. These include forms that have not changed in years. Stepping through the code in the debugger always results in a successful outcome. Trying multiple times consecutively would occasionally work. One or two computers still work reliably, though these have a source control addon called Ivercy installed. When you run the deployed version (without the addon active) these machines show the same unreliability.
Last week, we found more issues including some forms and reports that would not populate on initial opening. Reselecting the same filter date (or other rowsource changes) once the form is open brings up the expected set of rows. Again, loading the form while stepping through the code always works.
These behaviours lead me to believe there is some sort of fault that has been introduced in a recent Access update. Has anyone else seen this kind of problem?
One instance of this issue occurs on a very simple, one page report that has no user code in it at all. I would have been willing to believe that we had been doing something systematically wrong in our code, but this code-less report seems to suggest otherwise.
My machine (which exhibits the problem) is using Microsoft 365 Apps for enterprise
Version 2105 (Build 14026.20308 Click-to-Run)
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.
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.
I have an issue with a report causing an "Object reference not set to an instance of an object" exception when run through my web application. This is, so far, only happening on one QA machine.
I can:
Run the report locally on my development machine (latest code, same database)
Run the report through the Reporting Services Web Interface on the QA machine
Run the report on the QA machine through my web app if I select a format other than PDF/TIFF (e.g. Excel, CSV, HTML, XML all report successfully)
The Reporting Services log on the QA machine looks like this when I get the exception.
I did not find the log helpful so I started whittling the report down to a minimum to find the issue.
What I found confuses me.
Given the following RDL; I can change the height of Tablix list1 from 3.09444in to 1in, deploy the report to the QA server and the report will run successfully.
How in the world could shortening the height of Tablix list1 prevent the exception?
UPDATE
It's not moving height of the tablix to 1in. It's getting rid of the long decimal on the height. I changed (3.09444in to 3.1in) and the report ran successfully. FTR, I did not choose the height 3.09444in...rs chose that for me while I designed the report.
Fixed by changing the long decimal on the height of a Tablix from 3.09444in to 3.1in.
I did not choose the height 3.09444in.
The Reporting Services designer chose that for me while I designed the report.
I've experienced this problem a few times. It typically happens to me when I have a hidden textbox executing some Code.xxx routine and that textbox is located under a table, and the table has some kind of group page break.
It seems that with each page break, the fields hidden under the table are refreshed and sometimes they get a object reference error.
Here's the weird thing - I can typically fix the problem simply by moving all the hidden fields to a location such that their upper left corner is above the table's upper left corner, or to the left of it. It's like the position of the field somehow has some influence on what is refreshed and what is not.
I do not claim to know why it works, it just does.
I have an issue with a report causing an "Object reference not set to an instance of an object" exception when run through my web application. This is, so far, only happening on one QA machine.
I can:
Run the report locally on my development machine (latest code, same database)
Run the report through the Reporting Services Web Interface on the QA machine
Run the report on the QA machine through my web app if I select a format other than PDF/TIFF (e.g. Excel, CSV, HTML, XML all report successfully)
The Reporting Services log on the QA machine looks like this when I get the exception.
I did not find the log helpful so I started whittling the report down to a minimum to find the issue.
What I found confuses me.
Given the following RDL; I can change the height of Tablix list1 from 3.09444in to 1in, deploy the report to the QA server and the report will run successfully.
How in the world could shortening the height of Tablix list1 prevent the exception?
UPDATE
It's not moving height of the tablix to 1in. It's getting rid of the long decimal on the height. I changed (3.09444in to 3.1in) and the report ran successfully. FTR, I did not choose the height 3.09444in...rs chose that for me while I designed the report.
Fixed by changing the long decimal on the height of a Tablix from 3.09444in to 3.1in.
I did not choose the height 3.09444in.
The Reporting Services designer chose that for me while I designed the report.
I've experienced this problem a few times. It typically happens to me when I have a hidden textbox executing some Code.xxx routine and that textbox is located under a table, and the table has some kind of group page break.
It seems that with each page break, the fields hidden under the table are refreshed and sometimes they get a object reference error.
Here's the weird thing - I can typically fix the problem simply by moving all the hidden fields to a location such that their upper left corner is above the table's upper left corner, or to the left of it. It's like the position of the field somehow has some influence on what is refreshed and what is not.
I do not claim to know why it works, it just does.