Subject Re: [IBO] bugs on TIB_lookupcombo?
Author Helen Borrie
At 03:08 AM 10/06/2003 +0000, you wrote:
>Thanks for the clear explanation.
>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?

Maybe you misunderstand the use of the subquery that generates the computed
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

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.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:


You have to this *in addition to* defining the linking between the two
keys, viz.


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