At 06:52 PM 24-02-02 +0000, pepmallorca wrote:

>Hello Helen:
>
>I don't understand exactly what you want I do.
>
>I think my 2 masters are not alternative. Always I need a
>combination of the 2 masters (1 field of the first master, and 1
>field of the second master), give me the results of the detail.




>I tested your code in my program:
>
>SELECT idC, A, B, ....
>from TableC
>where A = :ParamA
>and B = :ParamB
>
>But I can have only one MasterSource, and the result than I get is
>empty for me if I write the second condition of the where.

Only one MasterSource at a time...but you can swap the Mastersource each
time you want to refine the detail dataset according to one master or the
other. This isn't a Master-Detail-Detail situation, since the two
"masters" (which you think are "details") are not related to each other.

The reason that DatasetC is the detail is this: you require for DatasetC
to be requeried when DatasetA scrolls or when DatasetB scrolls. The
reverse is not true. The requirement that you stated was to have DatasetC
respond to scrolling in A and B.

So the suggested SQL would take one of its parameters from the current
MasterLink and the other from the current row of the "non-current" master
each time DatasetA or DatasetB scrolls. Because DatasetA and DatasetB are
not related to each other, there is no "standard" MasterLinking that will
support the style of cascading on the client side that would permit
"automatic" updating of the indexer keys in DatasetC in response to an
insert or delete in DatasetA or DatasetB.

>For now I have find another solution, doing another combination of
>tables, but I'm interesting in your solution that seems very good,
>and it's possibly to solve another problems of this type.

I don't know about "other problems of this type", but your current
arrangement, with DatasetC as a parent with two dataset dependencies,
involves not a master-detail model, but a Keysource with two lookup
datasets. But a Keysource-lookup solution doesn't solve your problem of
wanting the parent to respond by supplying rows to match the
currently-selected row of either of the "dependent"
datasets. Masterlinking doesn't logically support a passive
master. Inverting the detail and master roles does solve it.

>Can you explain a little more with more detail?

Yes - in a separate reply, using your original posting, so we don't get
bogged down in confusion.


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