Alventis and Designer support creation of relationally-linked tables and InfoViews based on them. The overall concepts behind Relationality are explained in the chapter on Databases. Here, we will examine how this powerful feature works in Alventis and what you need to do in Designer to implement it.


You probably remember that to establish a relational link, a record of table A must be referencing another record from table B. This is achieved by having a special Pointer type field in table A. This field "points" to records of table B by storing their ID values. To establish a link between tables A and B then, all we need is a single Pointer field in A pointing to table B. Note that we are not using particularly precise terminology when we say the above. It would be more correct to say something to the effect of "value of the Pointer field from each record of table A points to some record from table B", but this is quite a mouthful, so we won't be very strict with our wording.

The field Type called Pointer is precisely the type we need.


Using an example very similar to the one from the Database Principles chapter, we must then ensure that the Contacts table has a Pointer field pointing to the States table. This field can be called anything we like, so we'll call it StatePtr. In the Contacts table, we shall create a new field, set its Type to Pointer, set its Name to StatePtr, and set its Pointer Target to States. That's it. Note that there's nothing that needs to be changed in the States table, which remains quite oblivious to the fact that some other table is now pointing to it.


With the relationship established at the table/field level, we must do the same at the InfoView level. There are two distinct kinds of Relational InfoViews that we can create, and we'll examine each one below.



Lookup Relational InfoView. This is the most obvious kind. Basically, we are basing the InfoView almost entirely on the main Contacts table: all fields that we place on the InfoView come from it. So, we end up with a rather ordinary looking InfoView with a bunch of Text Boxes for FName, LName, DateOfBirth, and the like plus one new item for the StatePtr Pointer field: the Lookup Combo Box. As described in the  Database Principles chapter, the Lookup Combo Box is a bit of a hybrid between an ordinary Combo Box and a grid. As a Combo Box, it is used to display and select the State that each Contact record points to (i.e., references or belongs to whichever terminology you prefer), which is its main relational operation. As a grid, it allows you to view and even edit the records from the States table directly in the drop-down grid. You can also easily open the desired States record by Alt-double-clicking it or hitting Alt-Enter when it is focused. Since the Lookup Combo Box has pretty much an entire grid attached to it, we must populate that grid. Since this grid is supposed to be displaying fields from the States table, this is the table whose fields we must drag into this grid (or "send" them there by double-clicking them).




The Lookup Combo Box's grid opens automatically when the item is created. If it's not open, you can do so by double-clicking the Lookup Combo Box. Once you're done with the grid, you must close it using the Close button on top of it. There's just one other element of interest here. Imagine you have added 3 fields from the States table to the grid (ID, Abbreviation, and FullStateName or something similar). When the grid is not dropped-down, the Lookup Combo Box only displays a single States field value but which one? If there's more than one column in the grid, we must explicitly tell it which one we want to see in the Lookup Combo Box in its closed state. We do so using the little combo box next to the Close button.





Reverse Lookup Relational InfoView. This is only slightly trickier. The fundamental idea is to base the InfoView mainly on the States table, and for each State record display all Contacts records that point to it.


The above idea gives us a strong clue as to what we can expect to find in such an InfoView. It's mainly based on the States table, so it shouldn't be too different from any non-relational form based on that table. This suggests that our form will probably have a bunch of fields from the States table scattered all over it. And how would such an "ordinary" form display a list of anything, and in particular of Contacts records? Well, a list seems to suggest a grid. Turns out this is exactly what such an InfoView looks like.




If we were to spell-out a "definition" of the Reverse Lookup InfoView, it would go something like this: it is an InfoView that contains one or more items implementing fields from the pointed-to table, and a grid implementing the pointing table.


In the above example, the "pointed-to" table is States, and the pointing one is Contacts (Contacts points to States, remember?). Note that the above "definition" does not specify what items are implementing the pointed-to table's fields. This is because it absolutely doesn't matter. It can be an array of Text Boxes or a grid (this one based on the pointed-to table and not to be confused with the other one that lists records from the pointing table), or even a combination of both. What is mandatory is that the pointing table be represented by a grid. It is also worth noting that nothing in the above "definition" suggests the order in which fields should be added to the InfoView and the grid. This is not a careless omission: the order does not matter. Designer allows you to start the InfoView as a completely "innocent" non-relational form, based on the pointed-to table, and then suddenly turn it into a relational one simply by adding a grid based on the pointing table. Conversely, an InfoView can start its life with just a single grid based on the pointing table (only a grid, no other field-based items!), and then become relational the moment you add a field from the pointed-to table. Either way, we end up with the very same result.