Portal filtering to specific number of records

[Agentshevy]

Hi all..  Can a portal be filtered to a certain number of records it can display..  For example, I have a portal that shows my contacts (100)..  I want to filter the portal to show only max of 10.. 

I have tried removing the scroll bar and limiting portal records to 10 via the portal settings, but I still have the feeling that filemaker actually served all 100 records just that I am being able to see 10..

 

Reason for my question : I have read that to enhance performance issues and fast loading of data especially via 3G networks, it is advisable to limit the records been served.. Such that only needed ones are served to the user... 

I don't know if I have really explained my point.. But I am available in case of any clarifications 

[LaRetta]

FM only fetches the number of records displayed in the portal.  Exceptions:  If the portal is sorted, if there is aggregate in the portal which requires the entire child table, or if the portal is scrolled.  Filtering the portal would not help you anyway since FM must fetch all related records to determine which to filter in or out, since filtering *normally takes place on the client.  Implement relational filters instead because, as the User scrolls, more records will be loaded.  But if the User scrolls, it means they need to see additional records so focus on what they are looking for and provide relationally filtered portals by intent and not size.

* When comparing local fields only to a constant value, FMS performs the action sending the results back to the client.  

In your quest to optimize ... one concept which helps is to create narrow tables because when a record is fetched, ALL fields except container are fetched.  For example, most people only display the same fields in the portal or list view ( the entity's primary name, date, purpose etc ).  Those fields should be in same table.  Fields which aren't referenced as often ( or only during detailed data-entry ) can go in a secondary ( related 1:1 table ).  In this way, viewing the portal is fast.  Then when one needs to edit the child records, switch to childDetails layout or provide popover where you set the child id of the selected portal record to a global with auxiliary relationship to chidDetails table, which loads only the single childDetails record.  Don't allow an edited record to commit until all changes have been made.  Each time you commit, the entire record is sent back to server.  Hold the commit and send the record back once, greatly reducing network traffic.

Limit the number of calculation fields by moving their logic to the layout ( conditional formatting, placeholder, merge variables ) and avoid ( like the plague ) calculations which reference other calculations which greatly hurt performance.  When possible, and you have very tight control, use script triggers to set static data instead of aggregate ( this is more advanced process which requires excellent protections because failure means your numbers will be off ).  

Good on you for asking the questions.  Never stop researching, asking or testing.

And check out these:

Design Performance

BTW, showing portals or related fields on parent list view means all the related records for all the parent records visible in that list are fetched so use lists wisely, using popover to display child fields if needed.

[LaRetta]

I wanted to say more on relational filters if you wish to stop scrolling ... you can set a global with list of child ids (first 10 then second 10 etc).  There are some great demos by Comment I'll try to find for you.  List ( child::id ) provides a list of all child records.  MiddleValues ( that list ; startingValue ; numberOfRows ).  Script can move User forward/back through the 'fixed' portal. 

added ... script sets global to complete the relationship.  With only 100 records, even portal filtering wouldn't be too heavy-duty.  Most of my saved links to posts are broken because of FMForums updates but here is one file by Comment which uses portal filter.  Keep in mind that we now have Refresh Portal which replace Refresh Window [ flush cached join ] and works in most instances and you probably want vertical instead of horizontal portal.

1273604490-HorizontalPortal11.zip

Edited November 23, 2015 by LaRetta

[Agentshevy]

Thanks Lareta, for really taking time to educate me more...  I guess I have to study your suggestions very well... Thanks