A layout has 4 fields in a portal, no containers. When scrolling through the 121 records in the portal, the spinning ball appears at each scroll, be it up or down (the connection is slow).
The file is hosted on a Mac Mini M1, FMS 19.1. I am the only user.
I am wondering why FMP does not store the entire list instead of re-loading parts of it each time I am scrolling some 5 records up or down.
Admittedly, this is not a direct answer to your question, but I am wondering if there are any heavy calculations in the portal row for conditional formatting/hiding, or even for the portal filter?
2 Likes
Does the base table for the portal table occurrence have a lot of fields and data? Or is your machine low on RAM and/or space on the drive?
1 Like
The base table provides a multi-line number field with UUIDs (the selection).
All fields shown in the portal belong to a second table.
There is no shortage of memory or disc space. Workload on the machine is quite low.
There are two hide object calculation. In list view, using the same calculations, scrolling remains fluid.
Thanks @Torsten.
Not sure if "base table" refers to the Layout context, or the Portal context.
If the case is the former, it sounds as though perhaps there is a multi-key relationship which drives the rows to be displayed in the portal? If so, by any chance is this using a technique that sorts the portal based on the order of the keys listed in the multi-key?
1 Like
Base table refers to the context. Indeed, the portal has a sort (text field).
I m wondering if possibly the sort field is an unstored value ?
1 Like
It is a calculated, stored field. I’ll give it a try and switch sort off for a test. Will be back tomorrow. Thanks @steve_ssh!
1 Like
Thank you, @Torsten, for indulging my curiosity and questions. I do not expect that a stored field for a sort would drag down the performance. The only last thing that I can think of would be if the table that is being displayed in the portal is several relationship hops away from the Layout context.
1 Like
Sorts applied on the portal cause the entire data set to be loaded (True in earlier versions. I think this is still true ) .
Filters applied on the portal cause the entire data set to be loaded. Unless the filter is a constant value that can be evaluated on the server. ( True in earlier versions. I think this has improved but don't know the details. )
1 Like
I never did any testing but would expect that only the related records to be sorted and filtered in the concerned portal.
@steve_ssh, I changed the field type from stored calculation to text with calculated value. This fixed it.
2 Likes
thanks for letting us know - now curious if changed back it stays fast or will be slow again? Suspiciously the index might not be present on the stored calc or somehow differently maintained then the auto-calc text field!?
Very interesting!!
1 Like
I could do that test some time later, as we are still in the thick of introducing a new major release (Yes, we work agile but still have major releases, i.e. new modules)
1 Like