Database Reference
In-Depth Information
Figure 14-23. You can create a new layout that makes it easy to see the invoices you need at a
glance. As you enter new dates in the global fields, the invoice portal updates on the fly, thanks to
the global multiple-criteria relationship that powers it.
FREQUENTLY ASKED QUESTION: DO I REALLY NEED A RELATIONSHIP?
Those new TOGs I made in the Invoice Finder tutorial seem like so much cruft in my database. Isn't
there a way to find Invoices that doesn't involve a portal?
Yes, there is, but this chapter is about relationships, so that's the technique covered here. And it's a
perfectly legitimate technique. But you're right to wonder whether the end result is worth the cruft.
In a relatively simple database, like the one you've been working on, a few new TOs aren't going to
be a problem, so the Invoice Finder TOG is just fine. And in a system where people are used to see-
ing search results in a portal, it might make sense to stick with that same visual solution. That way,
when you roll out their new layout, they'll understand what to do without training.
But in a large database where performance is a primary concern, you'll need to spend time and en-
ergy keeping the file, and its relationships graph, slim and trim. In that case, you could give users
the same effect as the Invoice Finder, by putting the two global date fields on an Invoice list layout.
Write a script that finds invoices with dates that fall between the start date and end date the user
enters in the global fields. Use a script trigger to run the script and you've given your users a new
way to find invoices that didn't require adding cruft to your relationships graph
Search WWH ::




Custom Search