any downsides to calculations?

[sal88]

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

[Tori Mitchell]

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.

[comment]

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).

[sal88]

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

[Sechwin]

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. :

[comment]

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.

[sal88]

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?

[bruceR]

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.