6 Replies Latest reply on Apr 20, 2017 6:56 AM by yomango

    Subsummary page brake

    yomango

      Hello, everyone. I've read some similar postings but can;t find an answer to my question. I have a two portal screen from which I want to make a report, printing on top the first portal data and below the second portal. On the print screen (using the second portal table layout) I've placed the first portal on a sub summary, gave it a few rows to show and adjusted it to expand or shrink depending of how many rows of data are used. On the body, I placed the data from the second data (no problem here, since the layout is from the same table used on that portal). Each part has a column header bar (a bit of a problem showing and hiding the bar, but that isn't my problem). The problem is that if the first portal has to use more rows than rows optioned to show, I lose data. Then I heard about virtual listings but the first portal has container fields, and I do not know how to go about virtual listing them. This way is beyond me, so far. Last, I created an auxiliary table to import data from the two portals, but I can't import every thing into the same fields, I have to have different fields to receive from the first portal and the second portal. No problem here. Then I created a sub summary based on a flagged field that lets me know which fields are from which portal. Placed all fields on the body (portal 2 fields on top of portal 1 fields, using a "Hide Object when" Inspector option. For the columns header I used the same option). Everything works fine up to here. My problem is to force the second portal information to a new page so the column header matches the data. Years ago, I remember I could force a report to break, let's say ,when a new month, a new supplier, etc happened. But I can't do it on FM 15. I used all the break occurrences available for the sub summary. And that's my question. (Too long?) I appreciate any help.

        • 1. Re: Subsummary page brake
          philmodjunk

          Your post would be easier to read if you broke it up into paragraphs.

           

          adjusted it to expand or shrink depending of how many rows of data are used.

          You cannot set a portal to expand depending on how many rows of data are used. You can only set it to shrink based on how many rows of data are used. The only mechanism that increases the number of rows in a portal are auto-size anchors and they are tied to the size of the window, not the number of related records in the portal.

           

          A description or screen shot of your relationships might be helpful so as to better understand what you are trying to put into your report and in what format.

           

          If possible, it's best not to use portals on reports as you encounter the very problems that you are reporting here. Unfortunately, there are cases where it's difficult to avoid using them.

          • 2. Re: Subsummary page brake
            yomango

            Hello, Phil. I think it is semantics, the portal expands up to the many rows I originally set it on the layout  and it shrinks when not needing all  rows. That's what I meant.

             

            The relationships I use to create a report  are Order Designs and Order Line Item

            But, as   mentioned before I went another way so not to use portals like you mention , by importing the data from these two relationships into an auxiliary table. An this is how the layout looks like: balck fields are  data from the first portal table, red ones from the second

            I might be going from LA to New York by the way of China, but works for me. The only thing is the page break:

            • 3. Re: Subsummary page brake
              philmodjunk

              It is semantics. "Expand" is a verb and nothing is expanding here. If you specify a 10 row portal, it doesn't expand to 10 rows, it just is 10 rows unless a smaller number of rows and a "sliding" setting shrink it down to a smaller number.

               

              One trick that I have used is to base the layout on one of the two child tables and to use a portal for the other. If the one portal is fairly static and doesn't need sliding within the portal for fields that need to vary in height, this can work in a number of cases.

               

              But in your case, it looks like you might insert a very small sub summary part and use part set up to specify a page break before every 1 occurrence of that sub summary part to force a page break with each new group of records.

               

              This is not perfect, I'd like to see FileMaker do better by supporting the option to repeat a sub summary part when it's group breaks between two pages, but it's not an option in the current version.

              • 4. Re: Subsummary page brake
                yomango

                "One trick that I have used is to base the layout on one of the two child tables", That's what I first did, to find out that if there are more rows than the ones specified, I can't see them when printed. That's why I went the second way by importing the data from the child tables into a temporary table and using it to create the report. But again, once the first group of records ends (third page on the screen pictures), I want to have a page break to start showing the second group and that the column header bar matches the group. As it is now, when the first group ends, there are two or three records (red fields) staying on that page, with no column header bar, where they should be jumping onto the next page. Is there a way to force that jump? Everything else is fine.

                • 5. Re: Subsummary page brake
                  philmodjunk

                  To repeat:

                   

                  But in your case, it looks like you might insert a very small sub summary part and use part set up to specify a page break before every 1 occurrence of that sub summary part to force a page break with each new group of records.

                   

                  And with regards to:

                  if there are more rows than the ones specified, I can't see them when printed.

                   

                  It can be necessary to set up the portal with a ridiculously large number of rows with sliding used to remove the unused ones. This can be combined with a calculation that counts the number of related records and displays a warning if the number of records exceeds the max number of portal rows. These are not perfect solutions, but can be made to work in some situations.

                  • 6. Re: Subsummary page brake
                    yomango

                    Thank you again, Phil. I'll see what I can do. I appreciate you taking the time to comment and advise