| Subject | Re: [IBO] 1:1 Relationship |
|---|---|
| Author | Helen Borrie |
| Post date | 2002-08-18T00:20:41Z |
At 12:25 AM 18-08-02 +0200, Heri Bender wrote:
provide lookup values for a key value which exists in the
parents. Typically, many different parent rows point to a single lookup
row. Technically, it would "work" for a 1:1 relationship - and the lookup
dataset is read-only by nature - but it would fall over in a 1:0 situation,
since the key-to-lookup relationship is obligatory.
(usually; although it can be an alternative unique key); this
relationship is the one which will select all detail rows with the linking
foreign key when the current row moves to a different primary key.
master-detail way by using a parameterised query for the detail instead of
MasterFields. Its effect is that your detail set expects to pick up a
parameter from events (such as scroll events) in the master set. IBO
provides good support (through MasterParamLinks) for this style of
linking. It is broadly similar to what the full-blown masterlinking does
"under the hood", but with less encapsulation; and the relationship is not
supported by the "follow-me" searching features that full masterlinking
provides.
A point about choosing full masterlinking over MasterParamLinks - with full
linking, you can set the master set to "follow" the detail set...IOW, you
can search the detail set and have the master set scroll to the
corresponding "found" primary key. You can't do this with MasterParams
linking.
you should upgrade IBO.
Just a further point about your application architecture...you said
<<
...Table B is edited only by triggers...
Table A will be shown in a grid for navigational purpose (in fact a simple
list with names), table B shows its fields in TIB_Edit controls which should
show the fields of the row matching the ID in table A
to your Table B controls, then you will have to do something to
a) display the editable fields of Table A
and
b) prevent editing of the Table B fields
There are a number of ways to do this visually. How I would normally
approach this is to lay out the form with my master scroll list in a
read-only grid (as you described) and two panels on the right-hand side of
the form. Panel A is the "editing panel" which displays the fields from
Table A that the user can edit (plus read-only fields if you have/need
them) and the read-only Table B fields as read-only TIB_Edits in Panel B.
At the dataset level, you would have a single dataset for Table A, to
populate both the read-only grid and the editable fields.
You can use the ColumnAttributes to set the edit/no edit behaviour of
individual fields of both datasets; although, in this case, I think you
want Table B's dataset to be completely read-only.
A variation on this could be to display both the Table A and Table B fields
in a single panel and "grey out" the read-only fields so that it's clear to
the user which fields s/he should attempt to edit. Read-only fields won't
get focus when tabbing through so it's usually less confusing to the user
to group all the editable fields together...
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
>Which method is more efficient for displaying data with IBO controls?No, this pattern is not for master-detail relationships. It is designed to
>
>Scenario:
>Two tables A and B, both with "ID integer primary key not null" field,
>linked 1:1 together. (triggers ensure the correct relationship, in fact
>Table B is edited only by triggers).
>Table A will be shown in a grid for navigational purpose (in fact a simple
>list with names), table B shows its fields in TIB_Edit controls which should
>show the fields of the row matching the ID in table A.
>
>Method 1: Use KeySource-Lookup Pattern? Keysource Table A, Lookup Table B
provide lookup values for a key value which exists in the
parents. Typically, many different parent rows point to a single lookup
row. Technically, it would "work" for a 1:1 relationship - and the lookup
dataset is read-only by nature - but it would fall over in a 1:0 situation,
since the key-to-lookup relationship is obligatory.
>Method 2: Use Master-Detail pattern? Master Table A, Detail Table BYes. The Detail set's foreign key points to the primary key
(usually; although it can be an alternative unique key); this
relationship is the one which will select all detail rows with the linking
foreign key when the current row moves to a different primary key.
>Method 3: ??It's also possible to cause the detail set to be restricted in a
master-detail way by using a parameterised query for the detail instead of
MasterFields. Its effect is that your detail set expects to pick up a
parameter from events (such as scroll events) in the master set. IBO
provides good support (through MasterParamLinks) for this style of
linking. It is broadly similar to what the full-blown masterlinking does
"under the hood", but with less encapsulation; and the relationship is not
supported by the "follow-me" searching features that full masterlinking
provides.
>Considering that table B is much bigger than table A in the rangeBoth styles of master-detail linking support an "empty" detail set.
>1000..100000 (other entities in the DB have also corresponding entries in
>table B. More precisely the relationship should be written something like:
>0..1 : 1 I don't know the official UML notation).
A point about choosing full masterlinking over MasterParamLinks - with full
linking, you can set the master set to "follow" the detail set...IOW, you
can search the detail set and have the master set scroll to the
corresponding "found" primary key. You can't do this with MasterParams
linking.
>4.2.GaIf you are using Firebird 1 build WI-V1.0.0.794 or its Linux equivalent,
you should upgrade IBO.
Just a further point about your application architecture...you said
<<
...Table B is edited only by triggers...
Table A will be shown in a grid for navigational purpose (in fact a simple
list with names), table B shows its fields in TIB_Edit controls which should
show the fields of the row matching the ID in table A
>>If editing is to be done on columns from Table A and there is no user input
to your Table B controls, then you will have to do something to
a) display the editable fields of Table A
and
b) prevent editing of the Table B fields
There are a number of ways to do this visually. How I would normally
approach this is to lay out the form with my master scroll list in a
read-only grid (as you described) and two panels on the right-hand side of
the form. Panel A is the "editing panel" which displays the fields from
Table A that the user can edit (plus read-only fields if you have/need
them) and the read-only Table B fields as read-only TIB_Edits in Panel B.
At the dataset level, you would have a single dataset for Table A, to
populate both the read-only grid and the editable fields.
You can use the ColumnAttributes to set the edit/no edit behaviour of
individual fields of both datasets; although, in this case, I think you
want Table B's dataset to be completely read-only.
A variation on this could be to display both the Table A and Table B fields
in a single panel and "grey out" the read-only fields so that it's clear to
the user which fields s/he should attempt to edit. Read-only fields won't
get focus when tabbing through so it's usually less confusing to the user
to group all the editable fields together...
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