Subject Re: [IBO] Keysource & Master Relationships Problem
Author Helen Borrie (TeamIBO)
At 05:05 PM 20-05-02 -0500, you wrote:
>There's something I do not understand going on here.
>I have a master dataset called Ticket.

Actually, the way you have this set up, you don't have a master dataset
called Ticket, since you have no other dataset that is pointing to it
through MasterSource and MasterLinks.

>A second dataset (Lading) feeds a
>LookupCombo on the Ticket screen, allowing the user to select a Lading.
>Finally, dataset Booking is tied to Lading via a MasterLinks relationship,
>so I get the booking that goes with the Lading that the user selects.

Lading is your master here.

>This all appears to work fine. The problem is when I attached an OnChange
>event to the LookupCombo to do this:
> qrTicket['CUST_ID'] := qrBooking['ORIG_ID'];

You shouldn't be trying to do this. In IBO, the dataset relationships
drive the events, not the controls. This code scrambles the relationships
which you have set up in the K/K and M/D relationships, since you have no
relationship here that ties qrTicket['CUST_ID'] to
qrBooking['ORIG_ID']. The way you have this set up (with a
KeySource/Keylinks relationship) the Lading selection determines two things
for this data structure: 1) the Lading which pertains to the Ticket and 2)
the Bookings which are associated with the Lading.

Also, OnChange in controls will fire *whenever* the current row in the set
changes, i.e. on scrolling the KeySource parent (Ticket), as well as at
other times when user selection is not involved. That makes it entirely
unsuitable to use as an interactive data event.

Keysource/Keylinks is is *not* a master-detail relationship...actually, it
inverts master-detail conceptually, insofar as one Lading can be pointed to
by many Tickets.

Master/Detail (Lading/Booking) here means one Lading can be pointed to by
many Bookings. In a sense, therefore, Lading is Master to two Details
simultaneously - although it isn't fully correct to regard it this
way. The K/K and M/D relationships are two members of a "Parent-Child"
paradigm and each is designed to behave differently.

The K/K relationship will cause the selected Lading to be written
automatically to the keylinked column in the Keysource dataset (Ticket)
(i.e. the behaviour that you were trying to force in your handler for the
LookupCombo). The M/D relationship will cause the detail dataset to be
restricted automatically to just those Bookings which pertain to the
selected Lading.

It appears that you want the selection of Booking to drive which Lading can
be selected for a Ticket? Would you confirm this? or otherwise explain
what you seek to do? If your ultimate aim is to tie Booking.OrigID with
Ticket.CustID as well as Lading.LadingID with Ticket.LadingID then your
current "raw" setup can't work.

>When that line of code is in there, I am only able to change the LookupCombo
>to other entries in the lookup list (Ladings) that have the same Booking ID
>as the currently displayed Lading. For example, if I am displaying Lading
>1234 that has BOOK_ID = 31, I can only select other Ladings that have
>BOOK_ID=31. I cannot select a Lading with a different BOOK_ID.

>If I remove the LookupCombo OnChange code, the user can select any Lading
>they want to.

That's true; and then the Bookings available will be only those that are
detail to the selected Lading. If there is no Booking having an OrigID
which matches the CustID in Ticket, you are stuck, since you would have to
find a way to insert a new set of relationships, which isn't possible with
this structure.

>I feel I'm missing something conceptually here. Can someone help? Thanks.

I can help (and others, I'm sure). But I think at this point you need to
get out pencil and paper and draw the relationships as they are statically
in the tables and as you want them to be dynamically in the
application. Then you need to design output sets that reflect your dynamic
requirements...more than likely you need at least one joined set (which
does not need to be visible in a control) to represent the cross-linked
relationships that Ticket displays. I doubt if a lookup relationship will
work at all with the "raw" structures you are using currently.

Helen Borrie (TeamIBO Support)

** Please don't email your support questions privately **
Ask on the list and everyone benefits
Don't forget the IB Objects online FAQ - link from any page at