Infinite Pages

rbuser

Hello, i'm having a lot of problems with infinite pages. I'm using
Delphi 2007 and RB 10.09.

I have one simple report that has 3 subreports in the detail band, and
each subreports has a lot of subreports inside without DataPipeline. I
use this because i have a lot of fields that has to be printed
depending on the value of one field. I have grouped the fields in
subreports and i set subreport.visible true or false depending on one
field value.

I usually have problems of infinite pages, and sometimes depending on
the default workstation printer, i get infinite pages in one
workstation and in another not, with the same report.

I have solved, by the moment, the problem putting one group in the
report, and assigning one value of the main pipeline to that group.

¿Why RB still has problems of infinite pages?. ¿Can not be controlled?.
That make me waste a lot of time with my customers.

Thanks.

nicocizik

Hi Jesus,

Take a look at the following article...

------------------------------------------------------
Article: TroubleShooting: Report Prints Endless Pages
------------------------------------------------------

Occasionally, we have customers state that their reports are in some
infinite state where page after empty page prints forever.

There are a few items to check when this occurs.

The TppReport.AutoStop property is the first thing to check. If this is
false when the DataPipeline property is unassigned, the endless report will
be the result. AutoStop is automatically set to True when DataPipeline is
set to nil, but it is possible to set it back to False. Check for instances
in your code where you might have created this condition.

Another thing to check is that all subreports in your report have their
DataPipeline set. When a subreport does not have its pipeline set, you will
sometimes see a condition where the first detail record prints and then you
get blank pages.

Another, non-data related cause can sometimes be your margin settings. If
you have stretching bands that need to overflow to the next page, if your
margins are too tight, sometimes the report engine will endlessly overflow
to the next page trying to fit the overflow material.

Still another cause might be having a statically positioned control, set to
ReprintOnOverFlow, in the same band with a stretching control. For instance,
if you have a memo set to stretch and in that same band, a label control set
to ReprintOnOverFlow, then on every page after the first, the memo will
begin to print after the label control. If the label is placed low enough
that the memo has no room to print, the report will forever be trying to
print the overflowing memo on the next page.


--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Nico Cizik (Digital Metaphors) wrote:



Hi,
you write "if your margins are too tight". What does that mean?
We also have sometimes this problem (with stretching bands). Changing
the margin just one millimeter usually solves it. But then -after weeks
and with other data- it happens again.

So I think there is no "correct" margin. It depends on data.

We also would be very interested in solving this.

Regards,
Josef

--

nicocizik

Hi Josef,

Which version of ReportBuilder are you using? We have made some
enhancements for recent versions that address some of these issues.

--
Regards,

Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com

rbuser

Nico Cizik (Digital Metaphors) wrote:



Version 10.04

--

rbuser

Nico Cizik (Digital Metaphors) wrote:

Hello Nico, i have tried everyting in the article before post. Making a
group with nosense in the main report has solved it. But why ?. The
problem to solve is that reportbuilder has to check that infinite pages
are not generated. Have to ckeck that if one subreport does not fit in
the current page, move it to the next, not generating infinites pages.

In any case i prefer thar reportbuilder cuts the printed band before
hanging up generating infinite pages. We have procesess that generates
reports autmatically and are stopped with reports that generates
infinite pages. We have started a timer and if the report is not
generated in 1 minute cancels it to prevent the problem, but the
reports are queued and not printed.

I think there must be samething to do with RB to avoid this error, that
i think is a RB error. If you know what can make RB to generate
infinite pages, you can solve it.

Thanks

nardmoseley

I recommend updating to RB 10.09. Send your serial number and registration
details to info@digital-metaphors.com and request download details for RB
10.09.

If you still have an issue, then as a test, try commenting out all
event-handler code associated with the report.

If you still have an issue, we need a reproduceable test case that can we
run here using the debugger. Please use standard Delphi components and RB.
Use the DBDemos data or dump some of your data to TClientDataSets or MS
Access. Send in zip format to support@digital-metaphors.com and we can check
it out.


--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com

nardmoseley

1. "Making a group with nosense in the main report has solved it. But why ?.
"

When a Group is added, it defaults to KeepTogether to True. That will cause
the report to page break very differently.

2. The Report.PageLimit property can be used to set a max limit for pages.
You can try using that as a safeguard to prevent the infinite pages.

3. For RB 10, we added an internal check to try to determine when a report
generates infinitely. Perhaps you have found a case where this internal
check does not help.

4. "Have to check that if one subreport does not fit in the current page,
move it to the next, not generating infinites pages..."

That is the current design. Now what if the object will not fit on the next
page? Then it looks to the next page - and so on, so you have infinite
pages. You have the report trying to generate, but something that is
supposed to fit on a page does not fit.

What would be helpful, is for you to create a test case that we can run
here. Please use standard Delphi components and RB. Use the DBDemos data or
dump some of your data to TClientDataSets or MS Access. Send in zip format
to support@digital-metaphors.com and we can check it out. here


--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com

rbuser

Nard Moseley (Digital Metaphors) wrote:


In my case, the bands are not too high, and each page contains 20/30
subreports bands. When infinite pages are generated, some times with 2
pages reports, the second page is not fullfilled, usually less than the
half of the page.


Is very complicated to make a test case because in the report we use we
have near 20 stored procedures, and that procedures select records from
near 50 tables. If you want to solve the problem, i can send you my
application exe, and connect to the database trough internet.

Thanks

nardmoseley

The first post in this thread starts like this "I have one simple report .."

Hmm...it appears this is far from an accurate description.

If you have a complex report that does not produce the correct result, then
I recommend trying to isolate the problem. Save the report under a new name
and incrementally make changes. Start simplifying the report until it quits
generating infinitely. Then start re-adding pages. Or start all over with a
new report and build it incrementally, testing each step along the way,
until it breaks.

Perhaps you have some event-handler code that is causing the report engine
to get lost.

Perhaps the data linking relationships are not properly defined.

Perhaps you have some page breaks defined that cause infinite generation.

Perhaps you have some components set to use KeepTogether that cause infinite
generation.

A report that does not work is similar to a program that does not work.
There can be a million reasons why it happens.


--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com

rbuser

Nard Moseley (Digital Metaphors) wrote:


I understand you,...., really the report template is simple, the only
difference with other reports is that has 3 subreports that has inside
another 5/6 subreports that are showed or hidden depending on one field
value. The report is simple because reads data from 5 stored procedures
that read data from nearly 30 tables, but is a simple reports with 5
pipelines.

We have checked everything before post, and with the group is solved. I
know that a report is like a program, but delphi is a program and hangs
up, and have errors.

If for you simple is one pipeline and one template with detail, then
the report is complex...

Thank you

nardmoseley

I recommend dumping the data to 5 TClientDataSets (TClientDataSet has
options to store data internally or locally.) Then create a new minimal
report that mimics your current report. Only include the minimum amount of
layout components and code required to reproduce the error. Then send in zip
format to support@digital-metaphors.com and we can check it out here.


--
Nard Moseley
Digital Metaphors
www.digital-metaphors.com