Advanced Relationship Techniques - FileMaker Pro 13: The Missing Manual - page 730

Function ) to test a condition before deciding whether to apply a filter. You can even use a
variable to filter a portal dynamically. That is, the portal's contents could change each time
the script runs if the value in the variable changes. Let your calculation wizardry rule the day.
NOTE
Portal filtering is most helpful where you expect the set of records to be fairly small, say fewer than
a couple of hundred or so. There's no hard-and-fast rule, but since FileMaker has to look at every re-
lated record to decide if it can pass through your filter, performance can suffer with large numbers of
related records. If a portal doesn't display records quickly, you may have to live with whatever cruft
it takes to make a multiple criteria relationship to do the same job. All that extra overhead does yield
a speed increase, so performance is a good determining factor in which method to use.
Understanding Table Occurrences
As you first learned on Creating a Relationship Between Two Table Occurrences , tables and
table occurrences aren't the same thing. Now it's time to dig a little deeper into that concept.
TOs are graphical representations of their source tables. As such, they describe which re-
cords you can view based on your current context. Because these occurrences are representa-
tions, you can make new occurrences of a table without duplicating it (and all its data).
FileMaker isn't trying to confuse you; it's helping you relate to the same table in different
ways.
Few databases can manage all their tasks without multiple occurrences of the same table.
You've already seen a couple of situations that call for new TOs on the graph. But there are
also functional reasons to create new TOs, too. For example, the Invoices database has an
Expenses table to record things you buy to service your customers. It also has a Line Items
table to record the charges on each Invoice. Right now these tables are connected only by
way of the Jobs and Invoices tables ( Figure 14-6 ).
Even though there's no direct line between Expenses and Line Items, they are related. Each
Expense record has a Job ID that can match an Invoice with the same Job ID. But there's no
direct relationship between any single Expense item and its corresponding Line Item, so you
can't look at an Expense record to see if it has been billed, or, if it has been billed, which In-
voice Line Item bills it. Of course you could type some text into the Line Items::Description
field to help you remember, but that's not very convenient from the Expenses point of view,
nor would that create a relationship between the tables. You really need a whole new rela-
tionship—one that connects Expenses and Line Items directly. This new relationship lets you
display Line Item data on the Expenses layout to make it completely clear that the item has