Database Reference
In-Depth Information
Figure 5-25. The Invoice portal shows all invoices that are attached to either of Mary Reynolds'
two jobs (Database App for iPad and User Guide). Placing the ID fields in a portal is a good way
to see how relationships work in theory. It's also a good troubleshooting tip if a portal or relation-
ship isn't working the way you think it should be working. Once you see the values in those ID
fields, it's easier to figure out what the problem is and how to fix it.
The records displayed in the Invoice portal show all Invoices that are related to any of the
customer's jobs. So if a customer has 20 jobs, the invoices from all those jobs appear in the
portal. When you think of this Invoices portal, it helps to think of it as a one-to-many- to-
many relationship. That's not a term you'll hear database developers using, but it makes the
concept more clear—one Customer is related to many Jobs, each of which in turn is related
to many Invoices.
Context is the key. From a Customer record, the context of the Invoice table is always
through the Jobs table. Because Customers are implicitly related to Invoices through Jobs,
you can copy the Invoices portal from the Customer layout and then paste it on the Jobs lay-
out, where it will behave perfectly without any extra work on your part. It will show slightly
different data in its new context, though. On the Customers layout, the portal shows invoices
from all jobs related to the customer. On the Jobs layout the same portal shows Invoices re-
lated to the current job only. The move works because you're moving a portal to a new con-
text along the same relationship line.
The Invoice table isn't the only one in the database that shares these properties. For example:
Search WWH ::




Custom Search