Database Reference
In-Depth Information
Figure 14-13. More TOs can actually reduce the overall confusion because now they aren't lumped
together in a long list. Here's the Current Table menu from the Specify Field dialog box. TOs are
grouped by Related and Unrelated Tables. When you're selecting a TO for a layout that shows re-
cords from the Expenses__Expenses TO, you only need to pay attention to the top group. Typing
the Table name of each TO in all caps makes it easy to pick the TO you need. Finally, when you in-
clude the names of the intermediary TOs in a name (Expenses_Invoices_LINE ITEMS), you can
easily tell which one is directly connected to Expenses, and which one is connected through the In-
voice table. Note though, that this menu should really refer to “Table Occurrences” and not
“Tables.” Just because FileMaker is confused, that doesn't mean you have to be too.
You can create many occurrences of a table, but each TO name has to be unique. Just as the
graph can become a mess without a TOG plan, you need a TO naming scheme (or naming
convention, as it's also called) to avoid creating wacky names that don't make sense in the
clear light of day. Here you'll use a convention that gives each TO name a prefix identifying
its TOG and that capitalizes the actual table name (Expenses_INVOICES) so you don't have
to guess which source table the TO uses. The new Expenses TO will become the context of
the new layout you'll create, so you'll type two underscores in its name (Ex-
penses__EXPENSES). That way, it appears at the top of the TOG group in a menu list, as in
NOTE
This naming scheme is one of many out there. Many developers use a similar scheme, but abbrevi-
ate the layout names/prefix part of the TO name (Exp_INVOICE), so the names don't get too
lengthy. Others refuse to use underscore in their TO names, and use camel case instead (Ex-
pensesINVOICE, for example). Feel free to make up your own scheme. Just use it consistently—it's
your breadcrumb trail home.
