Here’s an interesting twist on the usual from FileMakerHacks. As most developers soon figure out, the best way to display/print reports in FileMaker is to start with the proper context. For example, to print an invoice, the proper context is the table where the Line Item info is stored, not the table containing the Customer info or the Invoice info (invoice number, totals, etc.).
The reason for this is to allow printing across pages in all situations. It is possible to print from the other tables using portals, but what happens when you have a long invoice that requires more than one page? Portals don’t print well across page breaks, and the invoice doesn’t print properly. So the answer is to start from the line items table and put the related information about the customer and invoice in the headers and footers.
That’s the general rule. But sometimes, the rules must be broken:
The trick is to base the report layout on the state table, display the employees in a portal based on personnel, make sure the portal has more rows than any one state will never need, and that it is set to “slide up based on all objects above” and “also resize enclosing part”.
The benefit in this instance is to prevent data from breaking across a page–even though it is breaking properly, it can be confusing to the reader of the report in some instances to do so. So to properly format limited sets of data on a page, their solution was to go back to using portals! An interesting solution that is outside the box.
Read the rest of the post for the details and the limitations, and learn how to prevent your FileMaker reports from Breaking Bad across pages.