Unstirred (unstored but I liked the auto-correct result) calculations can certainly impact scrolling speed. As can fields shown via relationship from another table.
"Why do they call it rush hour when nothing moves?" ~Robin Williams
speed depends on
- unstored formulas
- related fields
- summaries/statistic fields
- pictures/graphics, etc.
- other factor
therefore, it's hard to answer without more information.. We got tables with 100'000s records, fast
What version of FM?
Running Filemaker 15 but the extension is fmp12 . Does it help if I went to the newer format ?
.fmp12 is the format for FMP15 files (and 12,13,14)
Make a copy of the layout. Remove all fields that are not from current layout context and all fields that are not normal stored fields. Test to see if the layout is fast. If it is then add back the other fields a little at a time until you find out what is slowing down the drawing of the records on the layout. Once you find that then you can ask for help for how to speed up the layout with that field on it if it is really needed on the layout.
I don't know how ill be able to speed it up because I designed a global search field to do my searching and below that I have a portal that is another occurrence of that table. The portal is Beer Name Search so when you search the top global field which is gsearchname , the portal changes its records with the search. Its fields in the portal are all calc fields that are just a simple substitute list . The delay is about a second and a half when you click on different records.
mentioned above - Summary Fields ... if you can move them out of the viewable area of the window, they won't be evaluated (until you resize the window, or scroll to see them).
I have no summery fields on the layout.
It seems to me from the information that you have listed here that you are doing a level of abstraction that is not needed. Can you add images of your layout and more of your relationship graph?
Another approach to speed things up is to cache the information. So you can run a script (even periodically on the server) to cache the related record up one level. Then it doesn't have to build the list on the fly as I think you are doing now.