Go to Related Record

 < Day Day Up > 

Go to Related Record

Go to Related Record is one of the most useful and important script steps. In this discussion of scripting, we've focused for the most part on categories of tasks that you can perform with scripts rather than on specific steps, but Go to Related Record , which we'll refer to as GTRR, merits a discussion entirely its own.

The Go to Related Record Options dialog is shown in Figure 15.7. Essentially, GTRR lets you navigate to one or more records that are related to whatever record you're currently viewing. As we discuss in this section, there are several options for how and where that related set will be displayed. It may take a while for all the nuances of GTRR to sink in, but mastery of this script step is crucial for becoming an experienced script writer.

Figure 15.7. Go to Related Record is one of the most useful script steps. It's also one of the most complex.

graphics/15fig07.gif


GTRR Basics

It might be helpful to think of GTRR as a way to move or jump from one point on the Relationships Graph to another point. But from where, and to where? In the GTRR options dialog (shown previously in Figure 15.7), the first thing you specify is the destination table occurrence for this move. The starting point for the move is determined by the script's context . We'll use the terms origin and destination to refer to these table occurrences.

Whenever a script executes, it does so in a context determined by the active window, the active layout, the active found set, and the active record. These things can, of course, all be changed during the course of a script through the use of a wide variety of script steps. The origin for a GTRR script step is determined by whatever layout is active at the point in the script that the GTRR occurs. The active layout situates you at a particular point on the Relationships Graph. So, managing the origin of the jump is done not in the GTRR step itself, but rather through navigation (if necessary) to the appropriate layout beforehand.

As the destination for the GTRR, you can select any table occurrence on the graph, including table occurrences tied to external tables, table occurrences that aren't related to origin, and even the origin itself. This last option produces a special result that's discussed in the "Jumping to Disconnected Table Occurrences" section a little further on in this chapter.

The other pop-up list within the GTRR dialog is for specifying a layout to use for displaying whatever set of records is returned by the GTRR. Unlike the choice of a destination table occurrence, you are restricted in your choice to selecting among layouts that are tied to the same table ( not table occurrence) as the destination table occurrence. That's a convoluted way of saying that you're expected to specify an appropriate layout to display the related set of records. We'll therefore refer to this layout as the display layout . If (and only if) the destination table occurrence is from an external file, you'll have the option to select the Use External Table's Layouts check box. The choices for the display layout consist of those layouts in the external file that are tied to the same table as the destination table occurrence.

Another option in the GTRR dialog enables you to specify that the related set of records appear in a new window. If you select this option, you have access to the same setup parameters that you do when using the New Window script step (window name , location, size ). If you don't check the Show in New Window option, one of two things happens when the GTRR is executed:

  • If the display layout is in the current file, then that becomes the active layout.

  • If the display layout is in a different file, then another window must be activated (windows are file specific). If there are not any windows for the required file currently open , then a new window is created (regardless of whether you've checked this option or not). If there are windows belonging to the external file (even hidden ones), then the frontmost of those in the stacking order becomes the active window.

The final option on the GTRR dialog is Show Only Related Records. You choice here partially determines what found set the display layout contains. It's easier to discuss the possible implications of selecting this option in the course of a specific example, which we do in the example that follows . For now, know that in the majority of cases, you'll want to enable this option.

GTRRA Simple Example

As an example of GTRR in action, consider the scenario of a database that contains information about teachers and classes. Figure 15.8 shows the Relationships Graph from such a file; there is a one-to-many relationship from the Teacher table occurrence to the Class table occurrence. The relationship is defined to sort by ClassName . There are two layouts in the fileTeacher Detail and Class Detaileach tied to the obvious table occurrence.

Figure 15.8. The two table occurrences in this Relationships Graph are connected on the TeacherID field.
graphics/15fig08.gif

Say that you want to use a Go to Related Record script step to "find" all the classes taught by a particular teacher. To do this, begin by navigating to the record of the teacher you're interested in. Place a button on the layout that performs a Go to Related Record step. Because the button is on the Teacher Detail layout, the Teacher table occurrence is the context in which the GTRR will be performed; it acts as the origin for the coming jump. In the GTRR dialog, specify the Class table occurrence as the destination for the jump. Finally, specify Class Detail as the display layout.

The found set and the sort order that will actually be displayed on the Class Detail layout depend on three things: what other options have been specified for the GTRR, the existing found set on the Class Detail, and the relationship settings that link the origin and destination table occurrences. The possible outcomes are as follows:

  • If you check the option to Show Only Related Records, then the found set consists of just those classes that are related to the current teacher record. Those records are sorted according the to the sort setting in the relationship, and the first record in the set is the active record.

  • If the option to Show Only Related Records and Show in New Window are both unchecked, the found set on the Class Detail layout depends on whether the first related record was already part of the found set there. If it was, then that record becomes the active record and the found set remains unchanged. If not, then all records in the table are displayed, with the first related record as the active record. The sort order of the display layout (here, Class Detail) is not altered in either case. Be aware that it's only the presence of the first related record that matters. In fact, it's possible that other related records may not even be part of the found set following the GTRR step.

  • If the Show Only Related Records option is not checked, but Show in New Window is checked, then all the records in the Class table will be in the found set, regardless of what found set existed there previously. The first related record is the active record.

  • If there are in fact no related class records for the given teacher, then the found set and sort order on the Class Detail remain unchanged. Further, the display layout does not even become the active layout. Be on guard for this, because if your scripts assume either that you have a particular found set or that you're on a particular layout following a GTRR, you might have problems. To trap for this situation, you can test for the existence of related records prior to the GTRR by using the Count function to determine the number of related records. Alternatively, you can check to see whether the GTRR step generates an error. Error 101, "Record is missing," is returned if there are no related records. Finally, if you had checked the option to "Show in New Window" and there are no related records, be aware that a new window is not created.

Predicting the Found Set

The preceding section contained an example of using GTRR to navigate to a set of classes that are related to a particular teacher. Because only one "hop" was involved in this GTRR, it was very easy to conceptualize what found set would be generated by the GTRR step. A GTRR, however, is not limited to short jumps such as this. In fact, the origin and destination table occurrences can be distantly connected on the Relationships Graph. When this is the case, it can sometimes be difficult to predict exactly what set of records will be returned. A few simple rules and examples should clarify this for you.

First of all, the origin and destination table occurrences must be connected on the Graph for the GTRR to function. If they aren't, the user sees an error stating that "This operation could not be completed because the target is not part of a related table." The actual error generated is error 103, "Relationship is missing."

Assuming that there is some unique path from the origin to the destination, you really need to know just three rules to determine what found set will appear if you do a Go to Related Record script step.

  • Every relationship along the path is evaluated.

  • The found sets are cumulative.

  • The sort setting of the final hop determines the sort order.

To discuss more concretely how these rules can be applied, it is helpful to consider some examples. Figure 15.9 contains a Relationships Graph with five table occurrences. The Teacher and Advisor occurrences are both linked to the Teacher base table. The other table occurrencesStudent, Enrollment, and Classare linked to base tables of the same names . In all the examples that follow, assume that the Show Only Related Records option is checked for all the GTRR steps. Starting from any of the table occurrences on the Relation ship Graph shown in Figure 15.9, can you predict with what found set you would end up if you performed a Go to Related Record , targeting each of the other table occurrences?

Figure 15.9. From any table occurrence on this graph, you can jump to any other location on the graph using a Go to Related Records script step.
graphics/15fig09.gif

Imagine that you were on the Teacher Detail layout. In the previous section, you saw how a GTRR directed at the Class table occurrence would find all of that teacher's classes. How about if you did a GTRR directed at the Enrollment table occurrence from the Teacher Detail layout? There's a one-to-many relationship from Teacher to Class, and another one-to-many relationship from Class to Enrollment. The GTRR would need to traverse two "hops," first to the set of classes taught by the teacher, and then to the enrollment records for those classes. The first hop might result in a set of, say, three classes. The second hop is the cumulative result of going to the related enrollments for each of the three classes. The end result would be a set of all the enrollment records for all the classes taught by that teacher.

What if you went one hop further, over to the Student table occurrence? The first two hops (Teacher to Class, Class to Enrollment) would again yield all the enrollment records for that teacher. The third hop, from Enrollment to Student, would yield the set of students that those Enrollment records represent. It's as if a GTRR were performed on each record of the found set of enrollments. The set of student records would represent all students enrolled in any of that teacher's classes.

Finally, what about a GTRR from the Teacher Detail layout all the way over to the Advisor table occurrence? Following the reasoning from the other examples, that would result in the set of teachers who are advisors for the students enrolled in any of that teacher's classes.

If any of the individual hops in a multi-hop GTRR yield a null set, then the entire GTRR behaves the same as a single-hop GTRR that yields a null set. See the preceding section for a discussion of this possibility.

As stated in the third "rule" earlier, the sort order of the found set in a multi-hop GTRR is determined by the last hop. In this example, say that there was a sort defined for the relationship from Class to Enrollment. Even though a GTRR from Teacher to Enrollment would yield a sorted result, a GTRR from Teacher to Student would not, unless the relationship from Enrollment to Student was also sorted.

There's one final point to make about predicting the found set of a multi-hop GTRR. If you're ever in doubt about what records would appear or in what order, simply create a portal that displays records from the destination table occurrence. The same set of records that shows up in the portal would end up as the found set after a GTRR. Assuming that the portal itself wasn't sorted, the order of the records would even be the same.

Jumping to Disconnected Table Occurrences

There's one final behavior of the Go to Related Record step that's worth noting: It can be used to move a found set from one table occurrence of a base table to another. This even works for disconnected table occurrences. In a given window, all the layouts associated with a given table occurrence share the same found set and sort order. This is a good thing because it means that moving back and forth between, say, a list view and a form view based on the same table occurrence doesn't require any found set manipulation.

However, if two layouts are attached to different table occurrences, their found sets and sort orders are independent of each other, even if they're both occurrences of the same base table. Say you have two occurrences of a Teacher base table called Teacher 1 and Teacher 2 on your Relationships Graph (either related or unrelated to each other). Imagine that you're on a layout associated with Teacher 1 and that you've done a find for some subset of Teacher records.

Now what do you suppose would happen if from that layout you were to do a GTRR that specified Teacher 1 as the destination and a layout linked to Teacher 2 as the display layout? The origin and destination are the same table occurrence here, so the answer might not be completely intuitive. The effect of such a GTRR, assuming you had checked the Show Only Related Records option, would be that the current found set and sort order would be transferred to the Teacher 2 layout.

So, by using the same table occurrence for both the origin and destination of a GTRR, you can move the current found set to another layout and/or window. There's something about this behavior that defies intuition, but it's very handy nonetheless.

 < Day Day Up > 


QUE CORPORATION - Using Filemaker pro X
QUE CORPORATION - Using Filemaker pro X
ISBN: N/A
EAN: N/A
Year: 2003
Pages: 494

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net