Page Break By Record

[ascharwath]

Hey all, 

 

I'm trying to find a way to insert a page break BY record. That is, mark a specific record in some way, and say no matter where that record falls in the layout, break the page afterwards until the next record. I've played around with a "break field" and sub summary parts a little bit but I can't seem to make it do what I want. Also, I don't want any of this mechanism to be visible when I print. Any thoughts? Thanks, 

 

-Andrew

[comment]

This is either difficult or impossible, depending on several factors. Can you explain in more detail what your report shows, and esp. how are the records sorted?

 

Also, couldn't you devise some criteria to identify the page-breaking records, instead of marking them manually?

[LaRetta]

I'm trying to find a way to insert a page break BY record. 

 

If the record's unique ID is included as the first leading part and included in the sort then page break before should work, shouldn't it?

[bruceR]

Page break by ID. No, I don't think so; if I understand the request correctly.

 

As I understand the request, the user wishes to arbitrarily choose a particular record to be the page-break record.

[David Jondreau]

Make a field to hold the "mark". Call it Break Record. Make it a number and use a check box with a 1 as the only value. Checking the box puts a 1 in the field. Unchecking makes it blank. records with a 1 will be where the page breaks.

 

Create a Summary field that =Total of Break Record. Set it to calc a running total.

Create a Calculation field equal to Max ( the new summary field minus Break Record ; 0 ) Set to evaluate when empty.

 

Add a tiny sub summary part to your layout when sorted my your new calc field. Set it below the body and set it to break after each 1 occurrence.

 

Mark records, sort by the calc field, and it should break where you want it.

 

*tweaked the calc

Edited November 5, 2014 by David Jondreau

[David Jondreau]

Here...check this out...

 

 

*Changed the calc slightly...

Test.fmp12.zip

[LaRetta]

Thanks for clarifying, Bruce. :-)

 

Hi David,

 

It seems quite expensive ... sorting on unstored calc of summary field (total of breakPage running)

Max ( Summary Break - Break Page ; 0 )

But still, it works!  Nice job!  :-)

 

Hi Andrew,

 

In all, I think I'd balk at using it unless the record set were small or it was not WAN.  It would sure help to see the file or understand the functionality since there may be other ways to solve the issue if we understood them.  

[David Jondreau]

LaRetta,

I think you'd be surprised how efficient this calc is. Unstored calcs get a bad rap, but it's undeserved. They are not necessarily slow, it's just they're used so often to reference related data which makes them slow. Referencing non-complex summary data is actually pretty quick.

 

I just ran a quick test and sorting by the calc on 600 records with a few dozen "breaks" over a WAN took about 2 seconds. Noticeably longer than sorting an indexed field, but certainly useable.

[LaRetta]

I cannot find a good argument against using it, that's for sure - we don't have enough information about the record set, environment etc.  However, 2 seconds to sort 600 records is quite slow so the reason for it had better be worth it.   When one has a slow connection such as mine (6Mbps download/.75Mbps upload), files which are snappy for those living in big fancy cities, drags to a crawl.  It's just slightly faster than dial-up, LOL, and is the only service available.  Much of the world is the same even still.

 

I suspect that, if the record count reached a few thousand, Andrew would be throwing his iPhone across the room.  OK.  Maybe not. I wouldn't throw an iPhone if I had one - those things are expensive!!   Developers need to plan with us pooh-connection folks in mind.

 

I really DO like your concept and I would still suggest finding alternate methods if possible, such as Michael's suggestion of identifying the criteria.  But your file is going into my tool kit of tricks!

[LaRetta]

Andrew is new to the Forum and rates himself a Novice.  It is quite possible that this need is a reflection of structural inadequacies or other such issue.  This is certainly not a normal request that we hear on forums ... and I've never heard of anyone needing this.  I smell other answers lurking around if we had more information.  For instance, WHY does the page need to be broken at a specific record?  Is it because it must fit on a certain sized paper?  If it is placement on a page (such as to allow for a picture), what if the record-set is sorted differently?  Is it because a group of records is printed and handed to a certain individual?  If so, why not set those records with the Individuals name or ID and find them individually or page break on that name instead?  

 

 

... no matter where that record falls in the layout, break the page afterwards until the next record

 

 

It sure sounds to me like the records need a field or calculation to identify them into groups.

[comment]

Create a Summary field that =Total of Break Record. Set it to calc a running total.

Create a Calculation field equal to Max ( the new summary field minus Break Record ; 0 ) Set to evaluate when empty.

 

 

1. What is the purpose of using the Max() function here?

 

2. If you would use Count instead of Total for the summary field, you wouldn't need to use evaluate always (and after all, it is the count we're interested in here).

 

3. I reserve my judgment on how well this works under varying circumstances. There's circular logic at work here: sorting a found set by the results of a summary field, which in turn depend on the current sort order themselves.

 

Note also that there will be a page break after the last record - which may or may not be the desired result.

[David Jondreau]

The Max() and Evaluate Always were to force a 0 instead of a Null value in the unstored calc for the initial records (until the first marked record). Using Count instead of total in the Summary() solves that. Which probably won't make a performance difference (all records need to be evaluated anyway) but is certainly more elegant.

 

How could there *not* be a page break after the last record? It's the last record.

 

It's definitely circular and a little "sketchy". But it worked in a few different scenarios (changing the order the fields were created, how the fields are placed, or not, on the layout, other sorting).

[bruceR]

"How could there *not* be a page break after the last record? It's the last record."

Bzzt. Does not follow.

[David Jondreau]

Bruce,

 

Perhaps you can helpful and explain your objection? The last record is on the last page. And the page breaks there. How can it be otherwise?

 

Maybe comment is saying that he thinks there would be a new, blank page after the page break, which isn't accurate. The last record of a record set is on the last page, whether or not there's a subsummary part afterwards that has "Page break..." checked.

[comment]

How could there *not* be a page break after the last record? It's the last record.

 

I thought there would be a page break after the last occurrence of the sub-summary part and before the trailing grand summary part. But apparently Filemaker doesn't take the "every" word literally...