Unstored calculations making the FM application as well as Web application very very slow

September 27, 201312 yr

Hi,

We have a Ticket Booking application using FileMaker 12.

hers is one of the chain os tables
Parent >> Child1 >> Child2

There are few calculation fields in Child1 which are either count or sum of fields in table child2 and hence those turn as unstored calculations. next these unstored calculations fields of child 1 are referred - sum up in the parent table and parent table also has unstored calculation fields.

On one of the layout which has portal of child 1 (with unstored calc fields) and also the unstored calc field of parent table, it takes time to load and sends application in not responding mode. It further aggrevates the problem when user starts "find" which uses data from unstored calc fields.

This is been extended on the web using PHP. So when the records are fetched from parent table from web application and if unstored calc fields are placed on the referred layout, web page execution is painfully slow. Can anyone suggest a work around to this as well?

Since this is a multiuser booking application it is important to get updated data in real time. Can anyone suggest an alternative solution for this? Mainly to replace use of unstored calculation fields? Or some radically different approach to this?

September 27, 201312 yr

You asked the same question yesterday on the FileMaker Dev Network forum and got some good responses there. So not sure if you don't believe that feedback and are hoping for a "quick cure". Well there isn't one. This is a fundamental data/workflow architecture decision that is coming back and hurting you.

Unstored calcs are great and easy but they come with a potentially huge performance price. That is a huge learning point for beginning FM developers who tend to over-use calculations at the schema level.

Get rid of the unstored calcs and set the fields as part of the user's workflow, back it up with a nightly server-side schedule to make sure no totals are inaccurate.

As mentioned in the other forum: pay attention to record-locks so you will want to make the updates in other tables a true transactional process where either all of it works or none of it.