Groups and Prevent Orphans
A customer has a complicated report with lots of subreports. They
noticed that a text field in a subreport's group header, if starting
right at the end of the page, will disappear once the report finishes
rendering in preview - but doesn't make it to the next page (this must
be a bug surely?). So they got around it by turning on "Prevent
Orphans", which worked well, until they discovered that global variable
running totals that are calculated in the subreport (as per
http://www.digital-metaphors.com:8080/RAP/Calculations/How_To...Access_Subreport_Values_in_the_Main_Report)
started to go wrong because the "details" BeforePrint/BeforeGenerate/etc
seem to fire more times than usual. This is definite a side effect of
turning "Prevent Orphans" on - turn it off an it corrects itself.
We have got around it by using the "Keep Together" option "only" in the
subreport's group - but its not entirely satisfactory as you can end up
with page 1 only being one third filled if the second group instance is
long and wont all fit on page 1 and thus goes to page 2.
So to sum up, two bugs: i) group headers on last line of page
disappearing and not making it to next page; ii) "Prevent Orphans"
causing too many "generations" in details so running total calcs go wrong.
Paul
N.B. I'm off on holiday now for a while, and but even if I had the
opportunity I really don't have the time to put together a sample report
that would work for you that illustrates the problem. Its 100%
reproducible here, so something must be wrong. Be grateful if RB team
could solve it in patch or next update. Thanks.
noticed that a text field in a subreport's group header, if starting
right at the end of the page, will disappear once the report finishes
rendering in preview - but doesn't make it to the next page (this must
be a bug surely?). So they got around it by turning on "Prevent
Orphans", which worked well, until they discovered that global variable
running totals that are calculated in the subreport (as per
http://www.digital-metaphors.com:8080/RAP/Calculations/How_To...Access_Subreport_Values_in_the_Main_Report)
started to go wrong because the "details" BeforePrint/BeforeGenerate/etc
seem to fire more times than usual. This is definite a side effect of
turning "Prevent Orphans" on - turn it off an it corrects itself.
We have got around it by using the "Keep Together" option "only" in the
subreport's group - but its not entirely satisfactory as you can end up
with page 1 only being one third filled if the second group instance is
long and wont all fit on page 1 and thus goes to page 2.
So to sum up, two bugs: i) group headers on last line of page
disappearing and not making it to next page; ii) "Prevent Orphans"
causing too many "generations" in details so running total calcs go wrong.
Paul
N.B. I'm off on holiday now for a while, and but even if I had the
opportunity I really don't have the time to put together a sample report
that would work for you that illustrates the problem. Its 100%
reproducible here, so something must be wrong. Be grateful if RB team
could solve it in patch or next update. Thanks.
This discussion has been closed.
Comments
This is not a known issue. Please understand that we are going to need
an example that recreates this behavior to have any chance of tracking
down the issue. Otherwise we are simply shooting in the dark looking
for problems.
Send the example in .zip format to support@digital-metaphors.com.
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com
I know exactly where you are coming from, but there must be better way
of managing issues like this? It could take me hours and hours to
contrive an example that you could run, or hours and hours for you to
create an environment that would support the report my customer has that
illustrates the problem in very strict data circumstances. I've never
bothered much about report archive files, but couldn't these be used to
capture the data and report in a single file that you could then somehow
work with. In Crystal Reports there used to be a "Save Data with Report"
option that allowed you do send someone a report that ran independently
on a database, although its only a loose analogy. Surely from a support
POV it would be great if we could all side step the issues with reports
that only run in specific environments (database server type, actual
data, custom reporting configurations etc) and just save them in a file
format from a preview screen so that the output could be sent to you for
investigation?
Paul
Unfortunately an archive will not give me the information needed to
track down an issue like this one. An archive is a snapshot of the
report output (similar to a PDF). This will show me that the output is
incorrect but will not process the report (Groups, Data, Layout, etc.)
so there is not way for me to tell what is happening.
I apologize but if we are unable to recreate an issue here, there is no
chance of us tracking down an issue with ReportBuilder. My first
suggestion would be to begin simplifying your report to try to isolate
the feature that is causing the problem.
1. Set SinglePageOnly to True and see if that helps first.
2. Comment out all event code associated with the report. If this
helps, periodically begin adding the code back to isolate the issue.
3. Begin setting certain report components visible property to False to
minimize the report output. This is a good way to isolate certain
report components that may be causing the issue.
Once you have done the above (shouldn't take longer than 30 minutes),
and have hopefully found the feature causing the problem, try creating a
simple stand-alone example that only uses this feature. If you need
data, simply use a subset of your data in a TClientDataset so you do not
have to include your complete setup. The example should not be more
than 100 lines of code and should not take more than an hour to create.
Nico Cizik
Digital Metaphors
http://www.digital-metaphors.com