March 7, 2007 at 1:00 pm
I'm using reporting services 2005 against a sql server 2000 backend. I have a fairly complex report with some subreports made visible as needed.
Normally, the report renders the 2900 pages in a few minutes. At times during development, the report hangs while rendering to PDF.
I can't isolate what the issue is. I thought it was down to a text box in a subreport. When I added it, it would hang, when I removed it the report would run. Then later, I added a new grouping to the main report and it would hang again. I can't seem to add new objects to the report without it hanging the pdf rendering. I go back to an old generation and it works.
Is there a limit to how complex a report can be or the number of objects you can have in it?
Any ideas how I can resolve this?
Thanks
Scott
March 12, 2007 at 8:00 am
This was removed by the editor as SPAM
March 12, 2007 at 12:46 pm
Check available Ram.
We've got a report that gives us the same type of problem when we run it against our larger customers. The report prints out the status of individual employees for the companies we serve. Reports for the smaller companies generate files, but larger companies fail. We think it is the issue of ram.
March 12, 2007 at 1:23 pm
No we're not having a problem with ram while it's running.
I was able to reproduce this problem over and over again. I narrowed the recordset down to a particular agency and even when I ran the report for that one agency it would fail. The recordset for the main report contains 59 rows and the subreport contains 20 rows, so it's not a large amount of data. We have agencies that are many times more complicated that print fine.
Strangely enough, I got it to work, when I pushed off the totals section to a subreport. That section had 2 running sums in it and some expressions based on data fields. I passed those over to the subreport as parameters and it worked fine.
This is not the only time, we've had this hang and had to look for a workaround. I also had a problem like this when I merged some columns in a table. The problem was happening to a completely different agency than before. Now when I develop in this report, I do one thing at a time, then deploy and run to be sure I didn't introduce another hang situation. It's so picky.
Is this behavior common to reporting services?
March 14, 2007 at 12:00 am
I had a similar problem when using a CrossJoin, but the data set was much larger. When I changed it to a NonEmptyCrossJoin, the world was at peace.
PDF is the second-most intensive rendering format, behind Excel. See if you can render the same report in, for example, MHTML.
December 2, 2009 at 8:23 am
Has anyone come across some tips for optimizing report exports to PDF, particularly in the case of large batch reports?
We just ran into performance issues with exporting a 10,000 page batch report to PDF. I did the obvious like having the user break the report into smaller batches and setting up subscriptions to have the PDF delivered to a file share. What's difficult is our old reporting tool was able to handle rendering up to 20,000 page batches in PDF more efficiently in terms of system resources and more quickly too.
I also checked the tables being rendered in the sub-reports to make sure they're not coming across as a graphic in the PDF. They're not and the report does not use a lot of graphics.
We're using SQL 2005 Standard, so scale-out is not an option right now. I was hoping some of you had some suggestions we could try for optimizing the report itself in some way.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply