Subject | Re: [IBO] bugs on TIB_lookupcombo? |
---|---|
Author | Helen Borrie |
Post date | 2003-06-10T03:30:43Z |
At 03:08 AM 10/06/2003 +0000, you wrote:
column. You'd want to do that where you want the user to see the
"description" value that the lookup key represents, rather than the key
itself. The lookup query typically would be something like
select colorkey, colorname
from Colors
Your Colors table looks something like this:
colorkey colorname
0 white
1 red
2 orange
3 yellow
4 green
5 blue
6 indigo
7 violet
8 black
On the parent row, you have stored the colorkey as the lookup key, i.e. the
color itself is not stored in the parent table, e.g.
select pk, item_id, item_name, ... colorkey
from itemtable
where....
So, to display the item with its actual color, rather than the colorkey,
you would add the correlated subquery expression to output the colorname as
well as the colorkey:
select i.pk, i.item_id, i.item_name, ... i.colorkey,
(select c.colorname from Colors c
where c.colorkey = i.colorkey) as color_descr
from itemtable i
You would set the COMPUTED attribute of color_descr true, the Visible
attribute of c.colorkey to False, and show color_descr in its place.
Down in the lookup query, you would then use KeyDescLinks to link the
non-key column back to the computed column in the parent:
COLORS.COLORNAME=COLOR_DESCR
You have to this *in addition to* defining the linking between the two
keys, viz.
COLORS.COLORKEY=ITEMTABLE.COLORKEY
The only connection with the DisplayField property is that you typically
want to display the non-key column of the lookup set, not the lookup key
itself. The Displayfield doesn't affect what gets written to the parent
when the lookupcombo is used to update the lookup key. It is the KeyLinks
which determines which lookup column is matched to the lookup key in the
parent.
Helen
>Thanks for the clear explanation.Maybe you misunderstand the use of the subquery that generates the computed
>
>How about the "inline query" is that necessary? As I mention in my
>previous posting I did not use the "inline query" yet I achieve the
>same result. Does the "displayfield" of the TIB_lookup combo has
>anything to do with it?
column. You'd want to do that where you want the user to see the
"description" value that the lookup key represents, rather than the key
itself. The lookup query typically would be something like
select colorkey, colorname
from Colors
Your Colors table looks something like this:
colorkey colorname
0 white
1 red
2 orange
3 yellow
4 green
5 blue
6 indigo
7 violet
8 black
On the parent row, you have stored the colorkey as the lookup key, i.e. the
color itself is not stored in the parent table, e.g.
select pk, item_id, item_name, ... colorkey
from itemtable
where....
So, to display the item with its actual color, rather than the colorkey,
you would add the correlated subquery expression to output the colorname as
well as the colorkey:
select i.pk, i.item_id, i.item_name, ... i.colorkey,
(select c.colorname from Colors c
where c.colorkey = i.colorkey) as color_descr
from itemtable i
You would set the COMPUTED attribute of color_descr true, the Visible
attribute of c.colorkey to False, and show color_descr in its place.
Down in the lookup query, you would then use KeyDescLinks to link the
non-key column back to the computed column in the parent:
COLORS.COLORNAME=COLOR_DESCR
You have to this *in addition to* defining the linking between the two
keys, viz.
COLORS.COLORKEY=ITEMTABLE.COLORKEY
The only connection with the DisplayField property is that you typically
want to display the non-key column of the lookup set, not the lookup key
itself. The Displayfield doesn't affect what gets written to the parent
when the lookupcombo is used to update the lookup key. It is the KeyLinks
which determines which lookup column is matched to the lookup key in the
parent.
Helen