Jump to content
View in the app

A better way to browse. Learn more.

FMForums.com

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

any downsides to calculations?

Featured Replies

Hi this is probably a daft question but i've come to the point in my life where i have to know for sure! :

If you can avoid using calculations should you do so? I'm asking this because surely it uses up more processing resources? or is stuff only calculated when it is needed as opposed to being calculated in the background all the time.

thanks

The calcs that you're referring to are processed on the fly when the data is pulled up. If you have the option to store the result enabled, this will be a permanent entry in the table. If you don't, it'll be a recalculation every time it's displayed in any way.

Calcs are an integral part of almost any FM system. The only advise that I've got for the utilization is to watch where you put aggregate calls and multiple-depth relations. Put too many of those in there and you're likely to see pretty significant perf drops.

A calculation field can be either stored or unstored. A stored calculation is recalculated when one of the fields it references is modified. An unstored calculation is calculated when it's needed (for example, when drawing a layout).

  • Author

So if you have calculation A that involves calculation B, then calculation B should be stored?

  • Newbies

Stored calcs use the processor once, then use storage and network resources until the next time they're changed.

Unstored get calculated again when they're referenced so use more processor.

It's okay to have a few unstored and even referencing an unstored. Just don't have too many. :

So if you have calculation A that involves calculation B, then calculation B should be stored?

Let me put it this way: if calculation field X is NOT stored, then any further calculation fields that reference field X will be forced to be unstored as well (same as when referencing a global field or a related field).

The question whether a field SHOULD be stored or not is a separate question. As noted, in some cases you don't have this choice. In some other cases, it can be a tough choice. Stored fields take up space, unstored fields hog the CPU.

  • Author

thanks guys got to grips with it now (i think). Could you give me some examples of when to use what. Would you have a record count that displays on the layout as unstored for example?

A record count must be unstored. Perhaps it helps to give it a different name - "live calculation". Otherwise record count is stored as the count of records at the time when you closed Define Fields.

Create an account or sign in to comment

Important Information

By using this site, you agree to our Terms of Use.

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.