Can anyone offer a good resource for understanding and creating advanced
calculations? I'm weak in this area and need to bone up on something with
references and examples. The kind of calculations I am interested in are
multi-field calculations. The kind that use multiple values from diffferent
fields.

-------------------------------------
Wes
http://www.LostPants.com
"we build applications to help
you keep your shorts!"

In message <HgwJc.96962$Oq2.18700@attbi_s52>, "Wes" <wchester (AT) lostXXXpants (DOT) com>
wrote:
In reading this post again, I realize that I worded this poorly.

I came across an FM dbase that had multiple calculation fields all drawing
data from each other. What I want to know is, how is the priority for
multi-calculation fields determined? Which one is calculated first?

- Wes

Wes wrote:
You mean circular references? If they are possible to define (I'd have
thought they'd be trapped and prevented), then you'd want to avoid them
at all costs.

There is -no- good reason to use a circular reference.

In article <RoMJc.36626$od7.16804@pd7tw3no>, 42 <42 (AT) nospam (DOT) com> wrote:

FileMaker won't let you create circular calculations (at least not in
any case I've ever tried).
ie.
Calc1 = FieldA + Calc2
Calc2 = FieldB + Calc1

This will cause an error message when trying to define the fields. This
is because Calc1 relies on the answer from Calc2, which in turn needs
the answer from Calc1, which wants the answer from Calc2, which ... As
you can see you get stuck in an infinite loop trying to recalculate the
answers.

BUT, what I think Wes is saying is if you have two (or more)
calculations, one based on the other, then which one calculates
"first".
eg.
Calc1 = FieldA + FieldB
Calc2 = Calc1 * FieldC

The answer (I think) is that since Calc2 relies on Calc1, then Calc1 is
evaluated "first". Of course the speed of these calculations mean that
you'd never really notice anyway - as soon Calc1 changes, Clac2 would
automatically recalculate.



Helpful Harry
Hopefully helping harassed humans happily handle handiwork hardships ;o)

Helpful Harry wrote:

Ah. Ok...

Case 1 - all fields are local to the file, and all fields are unstored.
No problem, FM will evaluate them on the fly, -as needed-.

[Although I'd hope it caches subresults in case they are reused.
ie I define a script that computes (calc2+calc2+calc2) I would hope it
just fully evaluates calc2 once. And there is strong evidence they are
cached.]

Case 2 - all fields are local to the file, and some fields are stored
calculations. No problem, FM will pull the results from the stored calc.
The stored calc will be updated when its source is updated. (FM
maintains dependancy tables)

Case 3 - fields are aggregates of calcs in related files. this one can
be tricky. if a script modifies a source field in a related record,
referencing a calculation field that is based on aggregate data from
related files can fail to reflect the update. I beleive this is because
the calculation result has been cached and marking a related record
doesn't invalidate the cache. The work around in my experience, has
always been to precede a reference to such a calculation in a scenario
where you have modified the source data in related files with the 'exit
record' script step. This appears to invalidate the cache and ensure
calculations are evaluated from scratch next time you reference them.

note that this isn't -always- the case, and I've never really pinned the
exact circumstances down, but I've encountered numerous situations where
FM failed to reflect data updates in -complex- calculations and
introducing an 'exit record' between the update and the reference has
always resolved it.

id be interested if anyone else has experienced this and pinned it down
more.

Case 4 - fields displayed on layouts. Being displayed on a layout will
trigger calculation evaluation when the screen is 'refreshed'. However,
changing the inputs to a calculation doesn't force a screen refresh.
This is why a 'status(currenttime)' field to display a clock doesn't
work. It also means, that if you are looking at a layout with a
'sum(relatedfile:A) and another user goes into related file and modifies
A, your screen won't reflect the update until -you- force a refresh.
(e.g. by advancing and retreating a record).