At 12:03 PM 21-05-02 -0500, you wrote:

> >
> > Lading is your master here.
> >
>
>Right. I was careless with my use of the word "Master".
>
> >
> > 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.
> >
>
>What you describe above is exactly what I want. My LookupCombo wasn't trying
>to assign the LadingID, but some other columns.

That's not how the K/K relationship works. Its purpose is to link the
lookup value in the lookup dataset with the keylinked key in the
parent. Once this relationship is formed, everything else has to follow.

You have a problem in your structure, in that relationship between Ticket
and Lading exists in two tables. Because of the M/D relationship between
Lading (master) and Booking (detail), as soon as you select a Lading_ID
from Lading, you force the Booking to be one and only one row: the one
that is linked to Lading by Book_ID. I see that a one-to-many relationship
between Lading and Booking is not possible because you don't have an
independent key on Booking. Therefore, a Ticket can be formed from one and
only one Booking record.

I note that your Booking-Lading structure actually makes it possible for
one Booking to master multiple Ladings. This makes things even more
confused, especially as I don't understand your requirements or how Lading
and Booking *should* relate to each other. It's possible, for example,
that you are storing the Lading_ID rather than Booking_ID on Ticket as a
way to link multiple bookings to a single ticket - a "family ticket" or
similar.

But you said:

> The user, while editing a new Ticket, can select a Lading, which (through
>M/D relationship) also gives me all Bookings (actually there's only one)
>associated with the Lading.

If the enforced 1:1 relationship between Booking and Lading is intentional,
then the only relationship that should be enforced by your application is
that between Ticket and Booking. The relationship between Booking and
Lading is taken care of by the 1:1 link through Booking_ID.

>Also, depending on whether the Ticket is for Purchase or Sale, I want to set
>some fields in Ticket. Take a look at this:
>
> qrTicket['RATE'] := qrBook['RATE'];
> qrTicket['UNIT'] := qrBook['UNIT'];
> if PurchSale.ItemIndex = 0 then begin
> qrTicket['CONT_ID'] := qrBook['O_CONT_ID'];
> qrTicket['CUST_ID'] := qrBook['ORIG_ID'];
> end else begin
> qrTicket['CONT_ID'] := qrBook['D_CONT_ID'];
> qrTicket['CUST_ID'] := qrBook['DEST_ID'];
> end;
>
>That's where I'm having my problems. Without the code above in the OnChange
>event, the Lading lookup and M/D for Booking worked fine.

I hope you can see how the cross-linked relationships are causing this
snafu. Applying values to ticket from the selected Booking row is no
problem. If there is a forced 1:1 relationship between Lading and Booking,
as seems apparent, then don't Keylink Lading to Ticket. Put it in a Combo
(not a LookupCombo) and use it as a selector for a Booking structure which
joins Lading and Booking and supplies the values to Ticket. You can then
masterlink this joined structure to Ticket through its Lading_ID.

regards,
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
www.ibobjects.com