Our company has a Filemaker database that uses conventional anchor-buoy relationships. Wherever possible, unstored calculations are minimized and NEVER EVER shown on list views. Summary fields are only used on reporting layouts….never employee-level interfaces. It’s hosted on AWS.
And, to boot, this is the second version of our app. We're currently using FMP 16 on 15 server, but we started off with FMP 14. The first was created by a very well-regarded developer in the FM community and was really, really slow. Exact same issues with a different app and different developers. Because of my SUPER-HIGH regard for this development team and their scrupulous attention to detail, I think the problem probably has to do with our process.
Our guys use MacBook Airs. Because many of the places where they use the app do not have wireless internet, they tether their phones to their MacBooks, and use that setup as an internet source for their laptops.
Roughly 60% of the time anything involving simple sorts on indexed fields in list views are really slow. We have to force quit often because of hangups. These sorts/finds/etc. are not on an inordinately large set of records….anywhere between 2,000 and 4,000. There are no summary fields to calculate on these layouts. Just text information. Now, we do have one math heavy table out there, but the point is that it doesn't matter which T.O the layout is based on. Even layouts that don't use any calculations beyond simple text concatenations are sludgy.
In the office, Filemaker, the iMacs use it just fine. The laptops are another story. Same internet, but different results. Hangups like crazy when switching to layouts that have sorts. Beachball city all the time. The guys who use laptops are practically begging to go back to spreadsheets. Also, anything that uses ExecuteSql(), be it a field or a script variable, stops these guys right in their tracks.
Anyone ever experienced anything like this….where problems are pretty much confined to laptops? Is it RAM