Chapter 19 -- Hierarchical Recordsets -- Pros and Cons

[Previous] [Next]

Chapter 19

For a number of reasons, the concept of hierarchical recordsets is enticing, and if you treat such recordsets right they'll do a lot of good for you. But you can't just take them out of the box and begin to use them; if you do, they're liable to hurt you and your application. The purpose of this chapter is to show you some gotchas that come with hierarchical recordsets and to show you how to get around these problems. For this purpose, we've created a small, simple three-tier application, the test form of which is shown in Figure 19-1. The source code for the test application can be found in the \Samples\Hierarchy folder on the companion CD-ROM.

You can easily see in Figure 19-1 that we didn't put much effort into making this form an elegant user interface; we just wanted one that could help us test our ideas and hypotheses. To the left, at the bottom edge of the form, you can see three ADO data controls. Normally we would hide them, but in this case we didn't see any profit in doing that since all we wanted to do was investigate the behavior of hierarchical recordsets under different circumstances.

It might also be interesting to see at least part of the data model we used for this example. Together, the data model shown in Figure 19-2 and the screen shot shown in Figure 19-1 should tell you most of what this application is all about.

click to view at full size.

Figure 19-1. A special test form, designed to test the behavior of hierarchical recordsets. Only one hierarchical set is used to present one race and all the entrants in that race.

click to view at full size.

Figure 19-2. Part of the data model for the application. This is the part we use as the basis for the hierarchical test.

In the combo box in the upper left corner of the form, you can see that the user has selected the Jägersro Galopp racetrack. In response to that selection, the application has listed all the dates on which races were ridden or are to be ridden on that track. This list is just below the racetrack combo box. In the data model, you can see the two tables used for the racetrack combo box and the racing dates list box:

  • The RaceTracks table, containing all the racetracks entered into the system. Each racetrack is identified by a value in the TrackId key column and further presented in the TrackName, City, and Country columns.
  • The RaceDays table, listing the date for each day on which races have been taking place. Each race day is identified by a RaceDayNmbr key value and further specified with the unique combination of a TrackId value and a RaceDate date. It goes without saying that the TrackId value is a foreign key that connects the race day to a specific racetrack.

Going back to the form, you can see that the user also has selected one of the listed dates. In the upper grid control, the application has listed some relevant facts on each race that was run (or is to be run) on the selected date. The user has already selected the third race, and the application has listed all the horses for that race in the lower grid object.

The information listed in these two grid objects lives in a single hierarchical recordset. The parent level of that recordset contains information about the races run on the selected date. The child level contains information about all the horses that run in any of these races; at least, that's what we wanted it to contain, but as you'll soon see, this isn't always the case.

Above the two grids, you can see three option controls. They helped us, when running the test application, to select from three different means of relating the parent and child part of the hierarchical recordset. We'll describe these means later in this chapter.



Designing for scalability with Microsoft Windows DNA
Designing for Scalability with Microsoft Windows DNA (DV-MPS Designing)
ISBN: 0735609683
EAN: 2147483647
Year: 2000
Pages: 133

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