7 Replies Latest reply on Feb 21, 2016 6:19 AM by disabled_morkus

    Realistic Portal Record Limits

      Is there a ballpark number of records you should display in a portal until it bogs down or does it just vary from application to application?


      Since my "many" table has varying numbers of matching records (anything from 20, to 140,000), I would either need to figure an efficient way to limit the portal records to some "reasonable" number based on the application, or just skip portals altogether for this particular 1:M relationship and, instead, use Finds, GTTR, or whatever.  Perhaps not surprising, a portal with 140,000 records in it is so slow it's unusable.


      Suggestions appreciated.


      - m

        • 1. Re: Realistic Portal Record Limits

          I think it depends on what do you do on the portal.

          Only showing data in portal may not problem with 140,000 records, it would be same as showing it in list view.

          If you try to "filter" the portal, or make calculation with it, or sort the portal, 140,000 may be unusable. But sorry I don't have the number what is the limit. It should be different in the file is shared or not.

          • 2. Re: Realistic Portal Record Limits

            It really depends on what you are doing the portal data... for example, filtering, sorting, and displaying unstored calcs in the portal can all be very taxing. FileMaker does not load every record in the related table just because you display a portal to that table. Typically it will load the records visible and then a buffer of maybe 15-25.


            However, if you sort or count all the portal rows, then you have an issue because FileMaker must process all the records to resolve the command.


            So the question is, what are you doing with the portal other than displaying the related data?


            -Emory Brown


            • 3. Re: Realistic Portal Record Limits

              It also depends on how many users you have, what data you have in the portal records, how fast the server is... for example at one place we have a portal-based agenda showing 60 portal lines out of 550'000, with 40 users on it, performing well. If you switch to 10 user view, thus showing 10 portals with 60 lines each (all pointing to the same table but with different keys), it still is decent.

              • 4. Re: Realistic Portal Record Limits

                I think you answered your own question!

                a portal with 140,000 records in it is so slow it's unusable


                The GTRR (go to related record) is a FIND, IMO. It is a quick way when there is a relationship to get to just those records without actually using a scripted find. Even a "filtered" portal need not have any records, but a "GTRR" button inside a single-row filtered portal will also "find" the narrowed set of related records.


                I believe "display" is the optimum point here. I agree that more than 15-25 related rows and it's probably not even good UI/UX to display a portal. I hate having to scroll more than that.



                • 5. Re: Realistic Portal Record Limits

                  Thanks Bev.


                  You posted at 3:20 AM? Are you doing FileMaker at this hour???   That's dedication.




                  Yeah, I thought the GTTR would be a better way to go as well. With huge amounts of data, taking advantage of indexes in relationships is important regardless of the platform.


                  Although everyone posted good ideas, I marked your answer as "correct" since it seems to me to match both what I was thinking and what I was observing in terms of performance.




                  - m

                  • 6. Re: Realistic Portal Record Limits

                    I'm on ET. The grandkid gets up early. 6:20 am? That's normal!