Database Reference
In-Depth Information
global fields and a portal based on the Invoice Finder_INVOICES relationship. For extra
credit, add script triggers (
Script Triggers
)
to the global fields that commit the records. When
it's all done, put values in the two global fields, and the portal updates to show the matching
invoices. See one possible arrangement in
Figure 14-23
. See the box below to learn another
way to create this same type of relationship.
NOTE
The Invoice Finder table has no records. You might think this would be a problem, but it isn't.
However, in some older versions of FileMaker Pro, portals don't work properly when you have no
records. If you run into this problem, just create a new empty record.
FREQUENTLY ASKED QUESTION: GLOBAL TABLE OR GLOBAL FIELDS?
I've already got relationships to my Invoice table all over my graph. Why can't I use one of them in-
stead of creating yet another Invoice TO? For example, I could put my global date fields into the
Jobs table and then use a portal filtering calculation on the Jobs-to-Invoice relationship to create
the same Invoice Finder. Is there a problem with that?
Not really. In fact, that approach would save you from creating the Invoice Finder table and the
whole TOG that made the layout work. The Invoice Finder layout would be based on the Jobs table,
and the portal filtering calculation would look a lot like the multiple criteria relationship you set up
in the tutorial on
Multiple Criteria Relationships
.
Using an existing relationship in a new way seems like a cleaner solution than adding new structure
to the database and graph. If you're comfortable with the fact that gStart Date and gEnd Date have
nothing whatsoever to do with a Job record and exist only to keep the graph streamlined, then your
plan will work just fine.
The main downside is that it might not be clear to another developer who has to work in your sys-
tem why you made that choice (unless you make a note on the graph, of course). The benefit of cre-
ating a global field table is that as a separate table and TOG, it's completely clear what its function
is. In fact, you might find other reasons to use global relationships and then that table could become
a repository for all the global fields that make similar features work. It would be rare indeed that any
changes you make to the database's other structure would affect this standalone global table or any
TOGs you hang from it. But it's your call.
