Your assumptions about portals (for printing) are correct. You can obviously see more portal records using a scroll bar when browsing.
You should always print 'portal records' by going to the detail table that the portal is based on, and printing from there. The report can then be as long or as short as it needs to accommodate all the records. You can create the header for the portal's 'parent record' by dragging in fields from the relationship back to the parent table.
Thanks for your help. So, clearly portals aren't the way to go. But, when I base my statement report layout on the transactions table (i.e. the 'detail table') I see all the transactions across all the accounts. I need the statements to only show the transactions associated with a particular account. So, it seems that some additional filtering is necessary. I implemented a solution that has 'next' and 'previous' buttons that are linked to scripts which automatically perform a find that filters out all but the transactions associated with the 'current' account. This works okay, but feels a bit messy. Is there a simpler way? I suppose what I'd ideally like is the concept of a 'portal part' that is behaviorally similar to a 'body part' but generates rows from the many side of a one-to-many relationship.
If you want to print the transaction list for the one record you are looking at, you can use the Go To Related Record script step, from that parent record to the child records in the Transactions. You can sort them by ParentID and have a leading sub-summary part with all the parent details in it. It will then only print the transactions for that one account. It is normal to freeze the window while that happens, so the user doesn't need to know that it is really changing layouts: it can be made easily to look exactly the same as the layout they are browsing.
If you want to browse in the Accounts table for a list of accounts and them print them all in one button, do the same thing, except speafy in the GTRR script step that the match should be 'All records in the found set'. Specify in the leading sub-summary part to take a page break after every occurance. It will then print a separate page(s) for each account you were browsing in the list.
Thanks again. It took me a while to get my head around your answer, but now that I have it looks like my transaction reports are going to be straight forward. I hadn't used the Go To Related Record script step before, but it is a much cleaner way of filtering than the script I wrote. Also, sorting by parent id and then using a leading sub-summary part to display parent records is the key to getting the behaviour I was looking for. Your help is very much appreciated.