Database Reference
In-Depth Information
The new relationship is ready to use.
Figure 14-1. The Invoices and Invoices_currentJob TOs are highlighted here. They're related by
the Job ID field in each table. When you put a portal from the Invoices_currentJob TO on the In-
voices layout, you'll be able to see all the invoices from the same job.
Now that you've created the Invoices to Invoices_currentJob relationship, put a portal from
the Invoices_currentJob TO on the Invoice layout (see
Creating and Using Portals
for a re-
fresher). Add the Invoices_currentJob::Date and Invoices_currentJob::Total Due fields to the
portal. To make the portal more functional, create a button that uses a “Go to Related Re-
cord” step (
Go to Related Record
) and place it in the portal. The GTRR step has to use the
same relationship as the portal: Invoices_currentJob. This is one of those rare instances
where a GTRR step can use the current layout. When you're done, you can click the button
to travel between all the invoices that are related to a particular job. To show financial in-
formation for the Job below the portal, create a
Sum()
calculation using this new relationship
and then display it on the layout below the portal.
Avoiding Ambiguity
FileMaker won't let you create any relationships that would make the graph ambiguous. To
understand what this means, recall the concept of
context
. That is, every TO is an instance of
a particular table, which provides the context for any layout that shows records from that TO.
So if you put the Jobs::Job Name field on the Invoice layout, it's as if FileMaker stands on
the Invoice TO and looks through a window (or a porta…get it?) into the Jobs table to get the
proper name for the job that's attached to the current invoice. Getting the job name is easy,
