Database Reference
In-Depth Information
It turns out the “Go to Related Record” command has an unexpected power: It can transfer a
found set—complete with current record and sort order—from one table occurrence to anoth-
er. The “Go to Related Record” Options window has a “Get related record from” pop-up
menu that shows every table occurrence in the database, not just the ones related to your cur-
rent context. It shows layouts attached to
any
occurrence of the same table. In other words,
when you ask to go to a record in the same table occurrence you're already viewing, you can
pick the Assign Expenses layout, even though it's associated with a different occurrence of
the Expenses table. If you want to get all geeky about it, you can call this technique “TOG
jumping” just like the pros do.
When you use this technique, FileMaker shows the records dictated by the relationship but
uses the layout you choose. To make the connection, add a button to the Expenses layout that
runs the “Go to Related Record” command. When you set up the button, choose the Ex-
penses table occurrence and the Assign Expenses layout. Also, make sure you turn on “Show
only related records.” FileMaker does all the rest of the work for you.
You can also add a button to the Assign Expenses layout that transports you
back
to the Ex-
penses layout. This time you configure the “Go to Related Record” command to use the Ex-
penses__EXPENSES table occurrence and the Expenses layout.
Understanding Graph Arrangements
The first TOG in your graph still looks and behaves like the ER diagram you drew on
The
Entity-Relationship Diagram
,
even though it has a few extra TOs in it. But you can see that
the more TOs you add to this group, the quicker its intended meaning will get lost in the
visual clutter. That's not to say that the TOG's behavior would change, only that you'd have
a harder time seeing the main tables' relationships at a glance. Because the graph's complex-
ity increases along with the features you add to your layout, finding an appropriate graph ar-
rangement early in your development is critical. Without a plan, you could end up with a
labyrinth, like the one in
Figure 14-11
.
NOTE
If you do end up creating (or inheriting) a messy graph, you can rearrange TOs or change their rela-
tionships. But calculations, script steps, and other processes that depend on the changed item could
break in the process. These types of developer-introduced bugs are time-consuming to trace and fix,
so most developers run a DDR (
The Database Design Report
) first and then use it as a map for fix-
ing the clutter.
