I have a report that consists of a number of subreports. When I export to
PDF I get blank pages on every second page. No data is missing, it looks
like an incorrect margin setting or additional page break. If I export the
original "Sub"reports to PDF, then the problem does not occur.
I have checked the margins in the report and the subreports, and they are
all identical. Does anyone have any ideas I can try?
AndreCheck your master report.
Look at your report width as well as your left and right margins.
"Andre" <Andre@.discussions.microsoft.com> wrote in message
news:05B0EB7A-8DE7-4323-A4AF-383F4E4D8543@.microsoft.com...
>I have a report that consists of a number of subreports. When I export to
> PDF I get blank pages on every second page. No data is missing, it looks
> like an incorrect margin setting or additional page break. If I export
> the
> original "Sub"reports to PDF, then the problem does not occur.
> I have checked the margins in the report and the subreports, and they are
> all identical. Does anyone have any ideas I can try?
> Andresql
Showing posts with label pages. Show all posts
Showing posts with label pages. Show all posts
Wednesday, March 28, 2012
PDF Render performance with SP1
Hi,
We have been working with some lrge PDF reports (200-400 pages) and have been anxiously awaiting
SP1 because of performance problems we have been having.
Our initial tests show that the performance is better: Given about 3000 records from SQL Server,
we generated a 272 page report.
Pre SP1: 4 minutes 35 seconds
With SP: 2 minutes 5 second.
So it is just over twice as fast. I also noticed that it is consuming less memory (roughly down
from 700MB to 400MB)
We still would like to get the performance much better and I'm looking for help to understand the
process and what we can do. In the past, running this report in MS Access and using ActivePDF took
10-20 seconds to generate the same report. Why is there such a disparity?
The SQL Query is taking 1-2 seconds at most, then all of the time is spent in aspnet_wp - all CPU,
negligible disk I/O. How do you suggest we identify the time spent?
Are there any tricks to making the report more efficient so that the PDF render time is better? Do
you have some favorite performance counters to watch to better isolate this?
We are trying to convert to using RS exclusively for our reports, but this performance may prevent
us from doing so - any help would be appreciated!
Thanks to all,
JamiIn general, the rules around RDL are much more complex than that of Access.
So much of the time may be in processing, not rendering. What is the time
for XML? Also, what type of data regions are you using (list, table,
matrix?).
Nonetheless, we will continue to work on both performance and size for
future releases.
--
Brian Welcker
Group Program Manager
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jami Bradley" <jbradley@.isa-og.com> wrote in message
news:vv3pd0hd8qupdap37f9e5rqn5c6pupi63k@.4ax.com...
> Hi,
> We have been working with some lrge PDF reports (200-400 pages) and have
> been anxiously awaiting
> SP1 because of performance problems we have been having.
> Our initial tests show that the performance is better: Given about 3000
> records from SQL Server,
> we generated a 272 page report.
> Pre SP1: 4 minutes 35 seconds
> With SP: 2 minutes 5 second.
> So it is just over twice as fast. I also noticed that it is consuming
> less memory (roughly down
> from 700MB to 400MB)
> We still would like to get the performance much better and I'm looking for
> help to understand the
> process and what we can do. In the past, running this report in MS Access
> and using ActivePDF took
> 10-20 seconds to generate the same report. Why is there such a disparity?
> The SQL Query is taking 1-2 seconds at most, then all of the time is spent
> in aspnet_wp - all CPU,
> negligible disk I/O. How do you suggest we identify the time spent?
> Are there any tricks to making the report more efficient so that the PDF
> render time is better? Do
> you have some favorite performance counters to watch to better isolate
> this?
> We are trying to convert to using RS exclusively for our reports, but this
> performance may prevent
> us from doing so - any help would be appreciated!
> Thanks to all,
> Jami
>|||We timed the XML output and it was just over 2 *seconds*. Our report is a list with sublists.
If you have any tips that may avoid performance issues with our reports, please let us know.
Thanks!
Jami
On Sat, 26 Jun 2004 00:25:50 -0700, "Brian Welcker [MSFT]" <bwelcker@.online.microsoft.com> wrote:
>In general, the rules around RDL are much more complex than that of Access.
>So much of the time may be in processing, not rendering. What is the time
>for XML? Also, what type of data regions are you using (list, table,
>matrix?).
>Nonetheless, we will continue to work on both performance and size for
>future releases.|||Well, XML is much easier than PDF. One thing that you should probably look
at is converting some of your report to tables instead of lists. Tables can
sometimes be faster to render.
--
Brian Welcker
Group Program Manager
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jami Bradley" <jbradley@.isa-og.com> wrote in message
news:cfc0e0ld0j45b4tbl6ic32tvskcod2ff3t@.4ax.com...
> We timed the XML output and it was just over 2 *seconds*. Our report is a
> list with sublists.
> If you have any tips that may avoid performance issues with our reports,
> please let us know.
> Thanks!
> Jami
> On Sat, 26 Jun 2004 00:25:50 -0700, "Brian Welcker [MSFT]"
> <bwelcker@.online.microsoft.com> wrote:
>>In general, the rules around RDL are much more complex than that of
>>Access.
>>So much of the time may be in processing, not rendering. What is the time
>>for XML? Also, what type of data regions are you using (list, table,
>>matrix?).
>>Nonetheless, we will continue to work on both performance and size for
>>future releases.
>|||We have been doing some testing with one of our reports and found a few interesting things. Here
is the basic information on what we did and how it affected the PDF size and PDF render
performance. All of the reports we ran were dominated by PDF render (checked in the execution
log). We were unable to get adequate performance from this report, so we solved this with a
different product, but I hope the information is useful to others.
All of these tests were using Report Manager - the processing time is the time for 'View Report' to
preview in IE, the PDF render time is the time to export to PDF from Report Manager.
A. Baseline Report (original form, desired report format):
10-15 seconds processing, 5:27 in PDF render, 508 pages, 10.6MB
B. Removed grouping and sub-report:
11 seconds processing, 2:10 in PDF render, 508 pages, 10.2MB
C. B with all details line drawing removed, and no logo (now a plain text report):
9 seconds processing, 1:00 in PDF render, 402 pages, 2.6MB
D. C with no line drawing in page header, avoiding overlapping text:
11 seconds processing, 52 in PDF render, 402 pages, 2.01MB
E. D with two fields removed (fairly complex nested iif expressions):
8 seconds processing, 46 in PDF render, 402 pages, 1.92MB
Items C, D, E had slightly different queries which reduced the row count from about 4500 to about
4000. Too bad I saw this late! I retested E with the proper row count to get the following
results:
E2. Corrected where clause to get all the rows:
9 seconds processing, 1:15 in PDF render, 451 pages, 2.16MB
So the conclusions? Grouping is dominating the time to get this report rendered (our grouping
simply puts a header line between groups). Line drawing makes the PDF significantly larger - this
is not too surpising, but other products seem to do this much more efficiently.
Good luck,
Jami
On Mon, 28 Jun 2004 22:43:17 -0700, "Brian Welcker [MSFT]" <bwelcker@.online.microsoft.com> wrote:
>Well, XML is much easier than PDF. One thing that you should probably look
>at is converting some of your report to tables instead of lists. Tables can
>sometimes be faster to render.
We have been working with some lrge PDF reports (200-400 pages) and have been anxiously awaiting
SP1 because of performance problems we have been having.
Our initial tests show that the performance is better: Given about 3000 records from SQL Server,
we generated a 272 page report.
Pre SP1: 4 minutes 35 seconds
With SP: 2 minutes 5 second.
So it is just over twice as fast. I also noticed that it is consuming less memory (roughly down
from 700MB to 400MB)
We still would like to get the performance much better and I'm looking for help to understand the
process and what we can do. In the past, running this report in MS Access and using ActivePDF took
10-20 seconds to generate the same report. Why is there such a disparity?
The SQL Query is taking 1-2 seconds at most, then all of the time is spent in aspnet_wp - all CPU,
negligible disk I/O. How do you suggest we identify the time spent?
Are there any tricks to making the report more efficient so that the PDF render time is better? Do
you have some favorite performance counters to watch to better isolate this?
We are trying to convert to using RS exclusively for our reports, but this performance may prevent
us from doing so - any help would be appreciated!
Thanks to all,
JamiIn general, the rules around RDL are much more complex than that of Access.
So much of the time may be in processing, not rendering. What is the time
for XML? Also, what type of data regions are you using (list, table,
matrix?).
Nonetheless, we will continue to work on both performance and size for
future releases.
--
Brian Welcker
Group Program Manager
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jami Bradley" <jbradley@.isa-og.com> wrote in message
news:vv3pd0hd8qupdap37f9e5rqn5c6pupi63k@.4ax.com...
> Hi,
> We have been working with some lrge PDF reports (200-400 pages) and have
> been anxiously awaiting
> SP1 because of performance problems we have been having.
> Our initial tests show that the performance is better: Given about 3000
> records from SQL Server,
> we generated a 272 page report.
> Pre SP1: 4 minutes 35 seconds
> With SP: 2 minutes 5 second.
> So it is just over twice as fast. I also noticed that it is consuming
> less memory (roughly down
> from 700MB to 400MB)
> We still would like to get the performance much better and I'm looking for
> help to understand the
> process and what we can do. In the past, running this report in MS Access
> and using ActivePDF took
> 10-20 seconds to generate the same report. Why is there such a disparity?
> The SQL Query is taking 1-2 seconds at most, then all of the time is spent
> in aspnet_wp - all CPU,
> negligible disk I/O. How do you suggest we identify the time spent?
> Are there any tricks to making the report more efficient so that the PDF
> render time is better? Do
> you have some favorite performance counters to watch to better isolate
> this?
> We are trying to convert to using RS exclusively for our reports, but this
> performance may prevent
> us from doing so - any help would be appreciated!
> Thanks to all,
> Jami
>|||We timed the XML output and it was just over 2 *seconds*. Our report is a list with sublists.
If you have any tips that may avoid performance issues with our reports, please let us know.
Thanks!
Jami
On Sat, 26 Jun 2004 00:25:50 -0700, "Brian Welcker [MSFT]" <bwelcker@.online.microsoft.com> wrote:
>In general, the rules around RDL are much more complex than that of Access.
>So much of the time may be in processing, not rendering. What is the time
>for XML? Also, what type of data regions are you using (list, table,
>matrix?).
>Nonetheless, we will continue to work on both performance and size for
>future releases.|||Well, XML is much easier than PDF. One thing that you should probably look
at is converting some of your report to tables instead of lists. Tables can
sometimes be faster to render.
--
Brian Welcker
Group Program Manager
SQL Server Reporting Services
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jami Bradley" <jbradley@.isa-og.com> wrote in message
news:cfc0e0ld0j45b4tbl6ic32tvskcod2ff3t@.4ax.com...
> We timed the XML output and it was just over 2 *seconds*. Our report is a
> list with sublists.
> If you have any tips that may avoid performance issues with our reports,
> please let us know.
> Thanks!
> Jami
> On Sat, 26 Jun 2004 00:25:50 -0700, "Brian Welcker [MSFT]"
> <bwelcker@.online.microsoft.com> wrote:
>>In general, the rules around RDL are much more complex than that of
>>Access.
>>So much of the time may be in processing, not rendering. What is the time
>>for XML? Also, what type of data regions are you using (list, table,
>>matrix?).
>>Nonetheless, we will continue to work on both performance and size for
>>future releases.
>|||We have been doing some testing with one of our reports and found a few interesting things. Here
is the basic information on what we did and how it affected the PDF size and PDF render
performance. All of the reports we ran were dominated by PDF render (checked in the execution
log). We were unable to get adequate performance from this report, so we solved this with a
different product, but I hope the information is useful to others.
All of these tests were using Report Manager - the processing time is the time for 'View Report' to
preview in IE, the PDF render time is the time to export to PDF from Report Manager.
A. Baseline Report (original form, desired report format):
10-15 seconds processing, 5:27 in PDF render, 508 pages, 10.6MB
B. Removed grouping and sub-report:
11 seconds processing, 2:10 in PDF render, 508 pages, 10.2MB
C. B with all details line drawing removed, and no logo (now a plain text report):
9 seconds processing, 1:00 in PDF render, 402 pages, 2.6MB
D. C with no line drawing in page header, avoiding overlapping text:
11 seconds processing, 52 in PDF render, 402 pages, 2.01MB
E. D with two fields removed (fairly complex nested iif expressions):
8 seconds processing, 46 in PDF render, 402 pages, 1.92MB
Items C, D, E had slightly different queries which reduced the row count from about 4500 to about
4000. Too bad I saw this late! I retested E with the proper row count to get the following
results:
E2. Corrected where clause to get all the rows:
9 seconds processing, 1:15 in PDF render, 451 pages, 2.16MB
So the conclusions? Grouping is dominating the time to get this report rendered (our grouping
simply puts a header line between groups). Line drawing makes the PDF significantly larger - this
is not too surpising, but other products seem to do this much more efficiently.
Good luck,
Jami
On Mon, 28 Jun 2004 22:43:17 -0700, "Brian Welcker [MSFT]" <bwelcker@.online.microsoft.com> wrote:
>Well, XML is much easier than PDF. One thing that you should probably look
>at is converting some of your report to tables instead of lists. Tables can
>sometimes be faster to render.
PDF render
Using RS/SQL 2000.
Is there a way to make the rendering of a report in PDF form any faster?
Currently takes about 40 mins for 10,000 pages. Only solution i can think of
is throw more hardware at it.
Thanks,
SPOOn Mon, 19 Dec 2005 06:01:02 -0800, iamspo wrote:
> Using RS/SQL 2000.
> Is there a way to make the rendering of a report in PDF form any faster?
> Currently takes about 40 mins for 10,000 pages. Only solution i can think of
> is throw more hardware at it.
> Thanks,
> SPO
I'd agree - throw more hardware at it, but I have to ask what everyone else
is probably thinking...
10,000 pages? What are you generating? Could anyone possibly look through
(or print!) a PDF containing that many pages?|||> 10,000 pages? What are you generating? Could anyone possibly look
> through
> (or print!) a PDF containing that many pages?
I don't see how or why.sql
Is there a way to make the rendering of a report in PDF form any faster?
Currently takes about 40 mins for 10,000 pages. Only solution i can think of
is throw more hardware at it.
Thanks,
SPOOn Mon, 19 Dec 2005 06:01:02 -0800, iamspo wrote:
> Using RS/SQL 2000.
> Is there a way to make the rendering of a report in PDF form any faster?
> Currently takes about 40 mins for 10,000 pages. Only solution i can think of
> is throw more hardware at it.
> Thanks,
> SPO
I'd agree - throw more hardware at it, but I have to ask what everyone else
is probably thinking...
10,000 pages? What are you generating? Could anyone possibly look through
(or print!) a PDF containing that many pages?|||> 10,000 pages? What are you generating? Could anyone possibly look
> through
> (or print!) a PDF containing that many pages?
I don't see how or why.sql
Monday, March 26, 2012
PDF file featuring only the first page... why?
Hello,
I am struggeling with my .PDF file exports. One of our reports outputs 250
pages in the web interface. When I ask to output a PDF version of it, the
file contains only the first page but I really don't know why. Could it be a
problem with the .RDL file?!?
Thanks!
Marc LacoursiereAfter some more inspection... I have found something interesting!
The report contains a table which has 2 groups. Both of them were set to do
a page break after them. If I remove the page break in the inner group, but
leave the other intact, the problem is fixed.
For this report, it is now working perfectly. But I am still wondering why
would the PDF rendering stop because of a table containing two groups both
doing page breaks?
Suppose I am required to create such a behavior in a different report, would
I still be stuck with that issue?
Marc Lacoursiere
"Marc Lacoursiere" <marcdotlacoursiere@.cgi.com> wrote in message
news:uroxxN$9EHA.3236@.TK2MSFTNGP15.phx.gbl...
> Hello,
>
> I am struggeling with my .PDF file exports. One of our reports outputs 250
> pages in the web interface. When I ask to output a PDF version of it, the
> file contains only the first page but I really don't know why. Could it be
> a problem with the .RDL file?!?
>
> Thanks!
> Marc Lacoursiere
>sql
I am struggeling with my .PDF file exports. One of our reports outputs 250
pages in the web interface. When I ask to output a PDF version of it, the
file contains only the first page but I really don't know why. Could it be a
problem with the .RDL file?!?
Thanks!
Marc LacoursiereAfter some more inspection... I have found something interesting!
The report contains a table which has 2 groups. Both of them were set to do
a page break after them. If I remove the page break in the inner group, but
leave the other intact, the problem is fixed.
For this report, it is now working perfectly. But I am still wondering why
would the PDF rendering stop because of a table containing two groups both
doing page breaks?
Suppose I am required to create such a behavior in a different report, would
I still be stuck with that issue?
Marc Lacoursiere
"Marc Lacoursiere" <marcdotlacoursiere@.cgi.com> wrote in message
news:uroxxN$9EHA.3236@.TK2MSFTNGP15.phx.gbl...
> Hello,
>
> I am struggeling with my .PDF file exports. One of our reports outputs 250
> pages in the web interface. When I ask to output a PDF version of it, the
> file contains only the first page but I really don't know why. Could it be
> a problem with the .RDL file?!?
>
> Thanks!
> Marc Lacoursiere
>sql
PDF Export Very SLOW ! MS Rerporting Services TEAM Where Are you ??
Hi,
I have a matrix report that produce 79 pages on the HTML browser in 30
seconds, but
if I try to export the report in a PDF format it take more than 1 our !!!
The system configuration is:
IBM Server with 2 Pentium Xeon of 2.4 Ghz
1 Gb of RAM
Fast network HD
Windows 2003 Server SP1 (SBS)
SQL Server 2000 SP4
Rerpoting Services SP2
Do you have any idea about this problem ?
I've saw there are some old messages about this problem on this newsgroup,
but nobody of the
Microsoft Rerpoting Service Team has reply !!!
I think this is a very important issue, that can KILL the reportin services
system on a
Serious Real World company application.
Thanks.
Cesar Augusto Flavio De Min.
MCSDEven 30 seconds for HTML is very slow. PDF definitely is much much slower.
Everything is done in RAM. 1 GB of RAM is pretty minimal. Is your data on
this server as well or just RS? Can you add more RAM to it. Perhaps bring it
up to 2 Gig. Also, an 80 page report while not huge is most likely taking
time due to complexity. You could try splitting it up into multiple reports.
I don't know if RS 2005 has improved performance of PDF rendering or not.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Cesar Augusto Flavio De Min" <cdemin_news@.yahoo.com> wrote in message
news:emEEYAO7FHA.2012@.TK2MSFTNGP14.phx.gbl...
> Hi,
> I have a matrix report that produce 79 pages on the HTML browser in 30
> seconds, but
> if I try to export the report in a PDF format it take more than 1 our !!!
> The system configuration is:
> IBM Server with 2 Pentium Xeon of 2.4 Ghz
> 1 Gb of RAM
> Fast network HD
> Windows 2003 Server SP1 (SBS)
> SQL Server 2000 SP4
> Rerpoting Services SP2
> Do you have any idea about this problem ?
> I've saw there are some old messages about this problem on this newsgroup,
> but nobody of the
> Microsoft Rerpoting Service Team has reply !!!
> I think this is a very important issue, that can KILL the reportin
> services system on a
> Serious Real World company application.
> Thanks.
> Cesar Augusto Flavio De Min.
> MCSD
>
I have a matrix report that produce 79 pages on the HTML browser in 30
seconds, but
if I try to export the report in a PDF format it take more than 1 our !!!
The system configuration is:
IBM Server with 2 Pentium Xeon of 2.4 Ghz
1 Gb of RAM
Fast network HD
Windows 2003 Server SP1 (SBS)
SQL Server 2000 SP4
Rerpoting Services SP2
Do you have any idea about this problem ?
I've saw there are some old messages about this problem on this newsgroup,
but nobody of the
Microsoft Rerpoting Service Team has reply !!!
I think this is a very important issue, that can KILL the reportin services
system on a
Serious Real World company application.
Thanks.
Cesar Augusto Flavio De Min.
MCSDEven 30 seconds for HTML is very slow. PDF definitely is much much slower.
Everything is done in RAM. 1 GB of RAM is pretty minimal. Is your data on
this server as well or just RS? Can you add more RAM to it. Perhaps bring it
up to 2 Gig. Also, an 80 page report while not huge is most likely taking
time due to complexity. You could try splitting it up into multiple reports.
I don't know if RS 2005 has improved performance of PDF rendering or not.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Cesar Augusto Flavio De Min" <cdemin_news@.yahoo.com> wrote in message
news:emEEYAO7FHA.2012@.TK2MSFTNGP14.phx.gbl...
> Hi,
> I have a matrix report that produce 79 pages on the HTML browser in 30
> seconds, but
> if I try to export the report in a PDF format it take more than 1 our !!!
> The system configuration is:
> IBM Server with 2 Pentium Xeon of 2.4 Ghz
> 1 Gb of RAM
> Fast network HD
> Windows 2003 Server SP1 (SBS)
> SQL Server 2000 SP4
> Rerpoting Services SP2
> Do you have any idea about this problem ?
> I've saw there are some old messages about this problem on this newsgroup,
> but nobody of the
> Microsoft Rerpoting Service Team has reply !!!
> I think this is a very important issue, that can KILL the reportin
> services system on a
> Serious Real World company application.
> Thanks.
> Cesar Augusto Flavio De Min.
> MCSD
>
PDF Export taking too long
I am using RS SP2 with SQL 2k SP4.
I have a fairly large report, in the region of a few hundred pages. It has a
couple of parameters that filters the data. I have it linked from a web
application and it goes directly to PDF. If the parameters are set the
report renders to PDF pretty quickly, the size runs from 1 page to 70 pages.
If we try to render the whole thing it just sits and sits and sits. I let it
run for an hour at one point at the report never appeared. The CPU is spiked
to 25% continually and eventually I have to do an iisreset to. Now I am
pretty sure, say 95% sure that this report worked fine with RS SP1 and SQL
2k SP3a.
So two questions.
Is there a known problem with large PDF exports?
Does anyone know if any third parties are selling PDF rendering extensions
for sql reporting services? I know there is at least one for Excel.So 1 - 70 pages is fast. How many pages is it if it is the whole thing? PDF
rendering and Excel rendering are very resource intensive.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Alex" <atelford6@.hotmail.nospam.com> wrote in message
news:O7cFPTVYFHA.2768@.tk2msftngp13.phx.gbl...
>I am using RS SP2 with SQL 2k SP4.
> I have a fairly large report, in the region of a few hundred pages. It has
> a couple of parameters that filters the data. I have it linked from a web
> application and it goes directly to PDF. If the parameters are set the
> report renders to PDF pretty quickly, the size runs from 1 page to 70
> pages. If we try to render the whole thing it just sits and sits and sits.
> I let it run for an hour at one point at the report never appeared. The
> CPU is spiked to 25% continually and eventually I have to do an iisreset
> to. Now I am pretty sure, say 95% sure that this report worked fine with
> RS SP1 and SQL 2k SP3a.
> So two questions.
> Is there a known problem with large PDF exports?
> Does anyone know if any third parties are selling PDF rendering extensions
> for sql reporting services? I know there is at least one for Excel.
>|||Good news and bad news
Good news is I have figured out the problem. Bad news is it does appear to
come from a PDF rendering bug.
We mad a minor change to the report and uploaded it, which is when we saw
the problem. I rolled back the report, redeployed and all is well, renders
290 pages in around 20 seconds.
The report has a table with 4 groups. On the third group we added a single
blank row above the group row. The group row contains some text. So for
groups #3 we have two header rows, one blank the other has a datafield. We
basically wanted to add some whitespace. With that extra blank row the
report with null parameters will not render and just pegs the CPU. If we
remove the row it works fine. If we supply a parameter to filter the report
it will render in both cases. I don't know at what point it breaks and I
don't really have the time to mess with it.
I will leave it without the whitespace for now but its very annoying to have
such a simple report change break the rendering.
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:%230WlwdVYFHA.3864@.TK2MSFTNGP10.phx.gbl...
> So 1 - 70 pages is fast. How many pages is it if it is the whole thing?
> PDF rendering and Excel rendering are very resource intensive.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Alex" <atelford6@.hotmail.nospam.com> wrote in message
> news:O7cFPTVYFHA.2768@.tk2msftngp13.phx.gbl...
>>I am using RS SP2 with SQL 2k SP4.
>> I have a fairly large report, in the region of a few hundred pages. It
>> has a couple of parameters that filters the data. I have it linked from a
>> web application and it goes directly to PDF. If the parameters are set
>> the report renders to PDF pretty quickly, the size runs from 1 page to 70
>> pages. If we try to render the whole thing it just sits and sits and
>> sits. I let it run for an hour at one point at the report never appeared.
>> The CPU is spiked to 25% continually and eventually I have to do an
>> iisreset to. Now I am pretty sure, say 95% sure that this report worked
>> fine with RS SP1 and SQL 2k SP3a.
>> So two questions.
>> Is there a known problem with large PDF exports?
>> Does anyone know if any third parties are selling PDF rendering
>> extensions for sql reporting services? I know there is at least one for
>> Excel.
>
I have a fairly large report, in the region of a few hundred pages. It has a
couple of parameters that filters the data. I have it linked from a web
application and it goes directly to PDF. If the parameters are set the
report renders to PDF pretty quickly, the size runs from 1 page to 70 pages.
If we try to render the whole thing it just sits and sits and sits. I let it
run for an hour at one point at the report never appeared. The CPU is spiked
to 25% continually and eventually I have to do an iisreset to. Now I am
pretty sure, say 95% sure that this report worked fine with RS SP1 and SQL
2k SP3a.
So two questions.
Is there a known problem with large PDF exports?
Does anyone know if any third parties are selling PDF rendering extensions
for sql reporting services? I know there is at least one for Excel.So 1 - 70 pages is fast. How many pages is it if it is the whole thing? PDF
rendering and Excel rendering are very resource intensive.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Alex" <atelford6@.hotmail.nospam.com> wrote in message
news:O7cFPTVYFHA.2768@.tk2msftngp13.phx.gbl...
>I am using RS SP2 with SQL 2k SP4.
> I have a fairly large report, in the region of a few hundred pages. It has
> a couple of parameters that filters the data. I have it linked from a web
> application and it goes directly to PDF. If the parameters are set the
> report renders to PDF pretty quickly, the size runs from 1 page to 70
> pages. If we try to render the whole thing it just sits and sits and sits.
> I let it run for an hour at one point at the report never appeared. The
> CPU is spiked to 25% continually and eventually I have to do an iisreset
> to. Now I am pretty sure, say 95% sure that this report worked fine with
> RS SP1 and SQL 2k SP3a.
> So two questions.
> Is there a known problem with large PDF exports?
> Does anyone know if any third parties are selling PDF rendering extensions
> for sql reporting services? I know there is at least one for Excel.
>|||Good news and bad news
Good news is I have figured out the problem. Bad news is it does appear to
come from a PDF rendering bug.
We mad a minor change to the report and uploaded it, which is when we saw
the problem. I rolled back the report, redeployed and all is well, renders
290 pages in around 20 seconds.
The report has a table with 4 groups. On the third group we added a single
blank row above the group row. The group row contains some text. So for
groups #3 we have two header rows, one blank the other has a datafield. We
basically wanted to add some whitespace. With that extra blank row the
report with null parameters will not render and just pegs the CPU. If we
remove the row it works fine. If we supply a parameter to filter the report
it will render in both cases. I don't know at what point it breaks and I
don't really have the time to mess with it.
I will leave it without the whitespace for now but its very annoying to have
such a simple report change break the rendering.
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:%230WlwdVYFHA.3864@.TK2MSFTNGP10.phx.gbl...
> So 1 - 70 pages is fast. How many pages is it if it is the whole thing?
> PDF rendering and Excel rendering are very resource intensive.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Alex" <atelford6@.hotmail.nospam.com> wrote in message
> news:O7cFPTVYFHA.2768@.tk2msftngp13.phx.gbl...
>>I am using RS SP2 with SQL 2k SP4.
>> I have a fairly large report, in the region of a few hundred pages. It
>> has a couple of parameters that filters the data. I have it linked from a
>> web application and it goes directly to PDF. If the parameters are set
>> the report renders to PDF pretty quickly, the size runs from 1 page to 70
>> pages. If we try to render the whole thing it just sits and sits and
>> sits. I let it run for an hour at one point at the report never appeared.
>> The CPU is spiked to 25% continually and eventually I have to do an
>> iisreset to. Now I am pretty sure, say 95% sure that this report worked
>> fine with RS SP1 and SQL 2k SP3a.
>> So two questions.
>> Is there a known problem with large PDF exports?
>> Does anyone know if any third parties are selling PDF rendering
>> extensions for sql reporting services? I know there is at least one for
>> Excel.
>
PDF export results in extra pages.
I am experiencing some quirks when exporting to PDF.
I have read all the other posts about page sizes, margins, etc and my situation seems to be a bit different.
I have read all the other posts about page sizes, margins, etc and my situation seems to be a bit different.
PageWidth = 21cm
PageHeight = 29.7cm
Margins = 1cm
Body.Width = 19cm
I have a report that contains a bar chart (Height = 15cm, Width = 19cm) and below that a rectangle that contains two text boxes with totals information (Left = 11.6cm, Width = 7.4cm, Height 0.5cm)
Now most of the time it exports to PDF perfectly - all on one page as would be expected
If however the chart has more than say 20 items on the y-axis then the rectangle gets pushed onto an new page.
For extra information, but not to confuse the issue I also have a page header and footer that have items lined up right to the edge (left + width = 19cm) and they all display fine on the one page. It is just this rectangle that is having the problem.
When I move the rectangle to the left a bit (11.4cm) so 0.2cm away from the right hand edge then it works fine.
It is just very strange because I cant see how it is getting shifted only when the chart contains a lot of items.
Any ideas?
I finally found a solution that works for me, just after I posted - usually the way.
I have created a rectangle with left = 0cm and width = 19cm and then placed the text boxes
inside that rectangle, positioned where I need them.
Once I do that it renders onto one page.
What I think is going on here is a precision problem. I suspect that MS being a US based company their base units are the imperial system so Inches. So even though you can express your measurements in cm, pt's, etc - they are always converted to a base unit of inches. With any conversion process you can get problems with precision and that is what I think is happening here.
So I feel the best way to avoid these precision bugs is to adopt a report design strategy of not having floating report items in your report. Group items by placing them in a rectangle and set the left to 0 and the width to the exact page width boundary (in this case 19cm)
The other solution is to always use the same base units as the renderer (inches) that way you wont suffer conversion precision problems. Unfortunately for me it would take forever to convert all mine from cm to inches.
PDF export error
When I try to export a 2400 pages report to pdf get the reporting services
error:
exception of type Microsoft.Reporting.Services.ReportRenderingException was
thrown. index was out of range. Must be non-negative and less than the size
of the collection. Parameter name: index.
The report ran before SP2 fine and after SP2 fine too.
Any help will be greatly appreciated.These are the error I get when debug.
A first chance exception of type 'System.ArgumentOutOfRangeException'
occurred in mscorlib.dll
Additional information: Index was out of range. Must be non-negative and
less than the size of the collection.
--
A first chance exception of type
'Microsoft.ReportingServices.ReportRendering.ReportRenderingException'
occurred in microsoft.reportingservices.imagerendering.dll
--
A first chance exception of type
'Microsoft.ReportingServices.ReportProcessing.WrapperReportRenderingException' occurred in microsoft.reportingservices.processing.dll
Additional information: Exception of type
Microsoft.ReportingServices.ReportRendering.ReportRenderingException was
thrown.
--
A first chance exception of type
'Microsoft.ReportingServices.ReportProcessing.WrapperReportRenderingException' occurred in microsoft.reportingservices.processing.dll
Additional information: Exception of type
Microsoft.ReportingServices.ReportRendering.ReportRenderingException was
thrown.
"Ehsan Khan" wrote:
> When I try to export a 2400 pages report to pdf get the reporting services
> error:
> exception of type Microsoft.Reporting.Services.ReportRenderingException was
> thrown. index was out of range. Must be non-negative and less than the size
> of the collection. Parameter name: index.
> The report ran before SP2 fine and after SP2 fine too.
> Any help will be greatly appreciated.
error:
exception of type Microsoft.Reporting.Services.ReportRenderingException was
thrown. index was out of range. Must be non-negative and less than the size
of the collection. Parameter name: index.
The report ran before SP2 fine and after SP2 fine too.
Any help will be greatly appreciated.These are the error I get when debug.
A first chance exception of type 'System.ArgumentOutOfRangeException'
occurred in mscorlib.dll
Additional information: Index was out of range. Must be non-negative and
less than the size of the collection.
--
A first chance exception of type
'Microsoft.ReportingServices.ReportRendering.ReportRenderingException'
occurred in microsoft.reportingservices.imagerendering.dll
--
A first chance exception of type
'Microsoft.ReportingServices.ReportProcessing.WrapperReportRenderingException' occurred in microsoft.reportingservices.processing.dll
Additional information: Exception of type
Microsoft.ReportingServices.ReportRendering.ReportRenderingException was
thrown.
--
A first chance exception of type
'Microsoft.ReportingServices.ReportProcessing.WrapperReportRenderingException' occurred in microsoft.reportingservices.processing.dll
Additional information: Exception of type
Microsoft.ReportingServices.ReportRendering.ReportRenderingException was
thrown.
"Ehsan Khan" wrote:
> When I try to export a 2400 pages report to pdf get the reporting services
> error:
> exception of type Microsoft.Reporting.Services.ReportRenderingException was
> thrown. index was out of range. Must be non-negative and less than the size
> of the collection. Parameter name: index.
> The report ran before SP2 fine and after SP2 fine too.
> Any help will be greatly appreciated.
PDF Export and extra pages
I'm having a problem exporting a report to PDF. In the viewer, the report looks great. When I export to PDF, all the group totals end up on a separate page. This inflates the pages by a great deal for a good size report.
I'm using SQL Server 2005 beta2 but I have also read about this problem in 2000 SP2. Does anyone have a solution to this? I'm going crazy trying to figure out the answer!!!
Thanks fir any replies,
Bill
The report width is too large.
Click on the main area of the report and observe the size in the properties.
Now click on the gray area outside the report and look at the PageSize and the Margins properties.
The width of the report itself must be less than or equal to the width in the PageSize property minus the sum of the left and right margins.|||Have you read the following blog article:
http://blogs.msdn.com/bwelcker/archive/2005/08/19/454043.aspx
I'm using SQL Server 2005 beta2 but I have also read about this problem in 2000 SP2. Does anyone have a solution to this? I'm going crazy trying to figure out the answer!!!
Thanks fir any replies,
Bill
The report width is too large.
Click on the main area of the report and observe the size in the properties.
Now click on the gray area outside the report and look at the PageSize and the Margins properties.
The width of the report itself must be less than or equal to the width in the PageSize property minus the sum of the left and right margins.|||Have you read the following blog article:
http://blogs.msdn.com/bwelcker/archive/2005/08/19/454043.aspx
It explains some of the "magic" related to page breaks and logical vs. physical page rendering.
-- Robertsql
Wednesday, March 21, 2012
Pause between pages when printing RS report
I am using Report Services on SQL Server 2005. I have a report that gets its data from a single SQL Server stored procedure. One other small table is used, but only to provide a list of values for selecting a parameter value to send to the stored procedure.
On the report I use a list control to display multiple records per page.
When printing the report (which currently produces over 500 pages - future printings of this report will not be nearly so large), the printer pauses between each page as if they are seperate print jobs. This is an HP LaserJet 5Si that normally cranks out reports very fast.
The only thing I can think of that might contribute to this sort of behavior is the fact that I set my margin sizes to 0in to get as much design room on the report as possible. Could that cause this sort of behavior?
Just bumping this topic. I'm very much in need of an answer on this. I've tried different settings for the margins as well, but anything other than 0in. causes extra pages to be printed.
How can I eliminate the pause between pages?|||How are you printing the report? Are you using the printing via the web or using delivery? I have not heard of this sort of behavior. The only thing I can think of is that the server is busy rendering each page and is causing the printer to wait for additional pages.
-Daniel|||Thanks for the reply.
I am printing the reports via the web. This behavior is exhibited when printing them from the Visual Studio design environment as well.
|||Most likely, your printer is able to print faster than the ability of the server to generate the pages. This could happen if the pages are complex and/or have lots of images. The overall time should be similar to exporting the report to an image format.|||I guess I can see where the report generation might be the bottleneck, however it is just a standard report with a basic list control displaying some 20-25 data fields per record. There are no images being used at all. The most graphically intensive element is a light gray filled box around the report title.
Honestly, I can't imagine a much simpler report. That is why I have trouble accepting this as being as good as it gets.
|||The fact that you see this in the designer as well as the server seems to mean that the issue may lie elsewhere. Do any other reports behave this way? Are you able to try any other printers?
When you print from the web you can preview the report first. Can you first preview the entire report before printing? By doing this you will have downloaded all the pages to the client, when you actually print you will just be sending the emf file to the printer. If the problem still occurs then it is most likely an issue downstream from RS if it doesn't occur then RS would have some issue.
Thanks.
-Daniel
Pause between pages when printing RS report
I am using Report Services on SQL Server 2005. I have a report that gets its data from a single SQL Server stored procedure. One other small table is used, but only to provide a list of values for selecting a parameter value to send to the stored procedure.
On the report I use a list control to display multiple records per page.
When printing the report (which currently produces over 500 pages - future printings of this report will not be nearly so large), the printer pauses between each page as if they are seperate print jobs. This is an HP LaserJet 5Si that normally cranks out reports very fast.
The only thing I can think of that might contribute to this sort of behavior is the fact that I set my margin sizes to 0in to get as much design room on the report as possible. Could that cause this sort of behavior?Just bumping this topic. I'm very much in need of an answer on this. I've tried different settings for the margins as well, but anything other than 0in. causes extra pages to be printed.
How can I eliminate the pause between pages?|||How are you printing the report? Are you using the printing via the web or using delivery? I have not heard of this sort of behavior. The only thing I can think of is that the server is busy rendering each page and is causing the printer to wait for additional pages.
-Daniel|||Thanks for the reply.
I am printing the reports via the web. This behavior is exhibited when printing them from the Visual Studio design environment as well.|||Most likely, your printer is able to print faster than the ability of the server to generate the pages. This could happen if the pages are complex and/or have lots of images. The overall time should be similar to exporting the report to an image format.|||I guess I can see where the report generation might be the bottleneck, however it is just a standard report with a basic list control displaying some 20-25 data fields per record. There are no images being used at all. The most graphically intensive element is a light gray filled box around the report title.
Honestly, I can't imagine a much simpler report. That is why I have trouble accepting this as being as good as it gets.
When you print from the web you can preview the report first. Can you first preview the entire report before printing? By doing this you will have downloaded all the pages to the client, when you actually print you will just be sending the emf file to the printer. If the problem still occurs then it is most likely an issue downstream from RS if it doesn't occur then RS would have some issue.
Thanks.
-Danielsql
pattern matching
hullo all,
well i need to read pages online using webclient or httmpweb classes
and store them in string builder to perform further string operations.
any idea regarding its code
This seems more like an application issue. You might try posting on one of the pertinent .NET forums.|||ummm well ur qoute proves true..
thanks
Subscribe to:
Posts (Atom)