Large graphs with many TOs produce a lot of data to transfer when a certain number of records is in the found set.
This works fine in a LAN environment. Over VPN this causes significant delays while loading and scrolling due to much smaller available bandwidth.
Re-writing the concerned part of a solution is one thing, but cannot be done overnight.
What is your experience with a larger file cache settings in order to mitigate delays in scrolling large lists?
How many fields are in the specific table? Maybe you could divide the table into two parts - with a 1:1 relationship. And for the list take the part that contains only the fields for the list. This could possibly take away ballast. Have no experience with this, it's just a guess.
Like in the party role model you could let the id’s be the same in both tables.
If you use FMP client then the use of the relationship to lighten the load is not going to work. That will only work for CWP and DataAPI clients.
The quickest strategy would be to reduce the number of records in the list.
Another strategy would be to mirror data in a table that is purpose built for the list view. For example, the list view may only need a few fields. In the mirror table you replicate all the IDs from the original table and then create a 1:1 relationship back to the original table. Create calc fields to dynamically pick up the data from the few fields you need. In that way you can create a very narrow table that is lighter than the original.
If I understand the concept, the mirrored table is for displaying data. Users are entering data in concerned layout. It is clearly over-optimised for fast-paced work on a list.
It is only today (the solution is online for over two years) that each user does not need to see the full list all the time.
Yes. It is a display concept. You could use scripted edits to manage data entry and push the changes back to the original table but that may be more work than you want to do.
An alternative is to split the table into two. Have one table that only includes the fields needed for the list. The other table can store all the other fields. In the form view, both tables can be combined.