4 Replies Latest reply on Jul 31, 2012 5:47 PM by JoeB_2

    Multi-page portals?

    JoeB_2

      Title

      Multi-page portals?

      Post

      I recently started using FileMaker Pro 12 to implement a database that stores account transactions. I need to produce a transaction statement reports that show the activity on a given account during a particular period of time. I have a one-to-many relationship between a table that holds account details (account number, holder name, etc.) and a table that holds transaction details (transaction date, type, amount, etc). Currently I'm using a portal in FileMaker to show the transactions for each account. This works okay, but it seems that portal can only display a fixed number of rows. I need to ensure that transaction statement are printed in full, spilling over onto multiple pages if necessary. Is it possible to do this with a portal? Or should I be using some other approach to listing the many transactions associated with each account?

      Any pointers appreciated,

      Joe.

        • 1. Re: Multi-page portals?
          Sorbsbuster

          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.

          • 2. Re: Multi-page portals?
            JoeB_2

            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.

            • 3. Re: Multi-page portals?
              Sorbsbuster

              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.

              • 4. Re: Multi-page portals?
                JoeB_2

                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.