Database Reference
In-Depth Information
Field Dependencies
Take a look at the example in Figure 16-3 to see how FileMaker knows when to recalculate
fields. Calculation fields often use other calculation fields in complex arrangements, as this
hierarchy of field dependencies shows.
First Name and Last Name are the only editable fields in Figure 16-3 . But they aren't the
only fields that can change. When someone edits a customer's name, FileMaker sees that it
needs to recalculate Full Name, which in turn triggers a recalculation of the Full Address
value. The recalculation trickles down through all the dependent fields as soon as someone
makes the change and then exits the First Name field.
Figure 16-3. This picture shows a series of interdependent fields. The Full Name field is a calcula-
tion field that uses First Name and Last Name. The Full Address field uses Full Name (and some
others not shown here). The fields in gray are unstored calculation fields. Collection Letter uses
Account Balance and Full Address. Account Balance in turn uses Balance Due. Since an account
can have several invoices, each with a balance due, Account Balance actually uses several balance
due values—one from each related invoice.
By contrast, since Collection Letter is an unstored field , FileMaker doesn't recalculate it
right away. (It doesn't need to recalculate if you aren't displaying the value anywhere on the
current layout.) Instead, the program waits until someone brings up the field onscreen and
t hen it runs the calculation on the current data, and displays the result.
That recalculates the Collection Letter value as FileMaker grabs the stored value for the Full
Address field. But it also needs the Account Balance, which isn't stored. So that field is re-
calculated first. That calculation requires the new Balance Due on each invoice in turn and
then they're added up to get an Account Balance. Finally, the database has the values it needs
to show you the Collection Letter.
Search WWH ::




Custom Search