Subject | Re: [IBO] Generators, Triggers, & TIBOQuery |
---|---|
Author | Helen Borrie |
Post date | 2001-01-26T04:23:51Z |
At 08:34 PM 25-01-01 -0600, you wrote:
because you have set GeneratorLinks in the link table, which is not what
you want. You want Master1 to generate KeyID1 and Master2 to generate KeyID2.
You have two masters and one detail here. The normal master-detail
structure can't handle that, so make the link set's mastersource and
masterlinks apply to Master1 and use a separate iboquery, inside the same
transaction context, to insert a new link row when you insert a Master2 row.
If your KeyLinks are correct, the relationships should fall into place
properly.
Rather than display the link set and Master2 separately, you might like to
consider a dataset that JOINs the two. The advantage of this is that you
can apply DML to Master2 to update both tables, without making the link
table visible.
I have such a situation in an app that has Teams and Members. Many members
can belong to many teams and I display several possible "views" of the
relationships in a treeview. In the same treeview, the user can select a
member and explode that member's team membership node; and can select a
team and explode its member list node.
Underneath this I have joined datasets between the link table and teams,
and the link table and members, respectively.
Take a look at the Survey App demo in your ibo ..\d4apps directory. Jason
has done something similar there for the Surveys and Questions tables.
If you haven't already, think about putting a surrogate primary key on the
link table and placing a unique constraint on the two "foreign" keys.
hth
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________
>I'm using TIBOQuery. I have a master-detail setup as follows:It indicates that the generator is getting called twice. This may be
>
> Master1 Link Table Master2
>
> KeyID1 KeyID1 KeyID2
> field1 KeyID2 fieldX
> field2 fieldY
> field3
>
>This is a many-to-many relationship. I have a grid for Master1 on a form
>and another grid to show what records from master2 are linked to it. I
>insert a record in Master2 which has a generator and a trigger so IB will
>automatically create a unique Key. After this new record is created KeyID2
>is returned and passed to the Link Table to link Master1 to Master2 for this
>new record. I'm getting an error on the applyupdates of the Link Table for
>it's KeyID2. When I manually go look at the record that was inserted in
>Master2 the KeyID2 is one higher than what was returned earlier. How is it
>getting incremented twice? Any ideas?
because you have set GeneratorLinks in the link table, which is not what
you want. You want Master1 to generate KeyID1 and Master2 to generate KeyID2.
You have two masters and one detail here. The normal master-detail
structure can't handle that, so make the link set's mastersource and
masterlinks apply to Master1 and use a separate iboquery, inside the same
transaction context, to insert a new link row when you insert a Master2 row.
If your KeyLinks are correct, the relationships should fall into place
properly.
Rather than display the link set and Master2 separately, you might like to
consider a dataset that JOINs the two. The advantage of this is that you
can apply DML to Master2 to update both tables, without making the link
table visible.
I have such a situation in an app that has Teams and Members. Many members
can belong to many teams and I display several possible "views" of the
relationships in a treeview. In the same treeview, the user can select a
member and explode that member's team membership node; and can select a
team and explode its member list node.
Underneath this I have joined datasets between the link table and teams,
and the link table and members, respectively.
Take a look at the Survey App demo in your ibo ..\d4apps directory. Jason
has done something similar there for the Surveys and Questions tables.
If you haven't already, think about putting a surrogate primary key on the
link table and placing a unique constraint on the two "foreign" keys.
hth
Helen
All for Open and Open for All
InterBase Developer Initiative ยท http://www.interbase2000.org
_______________________________________________________