Page break issue with subforms (1 Viewer)

Keith Nichols

Registered User.
Local time
Today, 04:59
Joined
Jan 27, 2006
Messages
431
My report has a number of subreports. If all the subreports have data, the detail section of the report will break onto the next page. So far so good. My problem is that the subreport at the bottom of the first page is breaking rather than printing all together on the next page.

Is there any way to set subforms not to break?
 

Keith Nichols

Registered User.
Local time
Today, 04:59
Joined
Jan 27, 2006
Messages
431
I think it will....

Rickster, thanks for the pointer. I will try this out today and reprot back.

From the link:

When designing a report which contains one or more sub-reports, there may be instances where the sub report grows large enough where it will span more than one page; with the headers and a portion of the detail on one page, and additional detail on another page. While it is possible to repeat the sub report's page headers on the new page, spanning two pages may not be desirable for certain types of sub-reports, where the data needs to be together.
Normally, if you place your sub-report in the main report's detail section, there is no way to enforce a "keep together" property for the sub report so that if the data on the sub report grows large enough, it will force a new report page to be printed containing the entire sub report, rather than splitting it in two.

Fortunately there is a work around available if you want to force a new page if the sub report spans more than one page. To implement the work around do the following:

1. In the sorting and grouping properties of the report, enter a "pseudo" group, whose name is a number, at the point in the report you want the sub report to appear, preceding the name of the "pseudo" group with an equals sign ( = ), such as: "= 1"

2. Set either the Group Header, or Group Footer property to "yes".

3. Place your sub-report in the Group Header or Group Footer, rather than in the detail section of the report.

4. In the properties for the header or footer (not the sub report,) set the "Keep together" property to "Yes".
 

Keith Nichols

Registered User.
Local time
Today, 04:59
Joined
Jan 27, 2006
Messages
431
This works a treat.

A few things to note:

1: My report has 9 subreports and so I loaded up 9 footers numbered 1 to 9. Curiously, the sorting and grouping shows the pseudo groups in the opposite order to the report itself. That is, if the sort and group shows 1 to 9, the report shows 9 to 1. Go figure. :confused:

2: I was able to name the pseudo groups in the sorting and grouping and this works fine, making the report design easier to work with as my subreports are sized to the height of the horizontal scroll bar and so you have no idea what they are without selecting them. However, if I named all the pseudo groups, the report ran correctly but gave a pop up criteria input box for every footer. If I leave one footer as a number, this doesn't happen. Until, that is, you save the database, when the groups all cause a criteria input box to appear again. Maybe there is some way of using a text identifier in the pseudo groups without prompting the action???:rolleyes:

Edit before posting!! - I modified the report query to include fields with the names of the footers and set them to '1' e.g. enter "PrjActions:1" in an empty column of the query design grid. This gives the footer a field to look at, but has no sorting effect due to all rows having a value of 1. Voilà! My footers now have text names that are meaningful. This doesn't work with spaces in the names (maybe quotation marks would solve this?), so it all has to be one word.:D

3: The footer keep together property needs to be set on the properties dialog, not the grouping and sorting dialog.

4: If the subreports can be empty, i.e. nothing to show on the report, you can set the footer property to 'Can shrink' or you will get blank space on the report where the empty footer appears.

5: There seems to be a limit of 10 groupings. If you have more subreports than this, then you may have to be even more creative to solve the breaking problem. Post back if this is you and you solve the 'problem'.

Altogether, not a bad workaround.

Thanks again Rickster57.
 

Rickster57

Registered User.
Local time
Yesterday, 18:59
Joined
Nov 7, 2005
Messages
431
reports

Thanks for reporting back Keith. I did not have time to try it but looks like you got it worked out in case the rest of us need this solution at a later date.
 

Users who are viewing this thread

Top Bottom