1 Reply Latest reply on Feb 18, 2015 7:47 AM by philmodjunk




      Power & Patients


      Are different type of calculations handled better than others by FileMaker and it resource management? What I mean is that when I was newer to FileMaker the volunteer community leader gave the good advice that you don’t want to have a large number of un-stored calculation on a layout. It seems like calculations like Sum () and one that use simple math are less demanding than something like an ExecuteSQL statement. This makes sense if so. I am wondering about this when I am building solutions do I need to choose a way to calculate that get the job done best or if I should be conscious of power and processing. Thanks

        • 1. Re: Power & Patients

          Unstored calculation update on demand. Stored calculations update when a referenced field changes value.
           Conditional Formatting/Hide Object When expressions update continually.

          How much time a given calculation takes to evaluate is a function of many different variables, but those that compute an aggregate value-a value from a set of records--such as a summary field or the Sum() function will take much more time than those that do not compute such a value. The amount of time it takes for an aggregate value to compute will be a function of the number of records that supply data to that aggregate value. This is why you don't want to show all records on a layout with a summary field or two if you have millions of records in the underlying table.

          ExecuteSQL calculations, in my experience, vary a lot in how long it takes them to evaluate since the query expressions I might construct will vary greatly in complexity and in the number of records in the tables the expression queries. If I recall the details correctly, this SQL has be be run by FileMaker through an interpreter to in order to execute the query, which requires even more processor cycles to evaluate. And the SQL expression might even include aggregate functions as well to further add to the "computation load" of a given layout that displays data from such a calculation field.

          So your worse case scenario might be a conditional format expression that uses a sum function inside an ExecuteSQL query with Joins to several multi-million record tables and a complex multiple term WHERE clause....

          Ultimately, you may have to test your layouts with realistically scaled sets of records and be prepared to remove different layout elements during testing to see how much such a change affects how your layout updates.