At 05:17 PM 16-09-02 +0200, you wrote:

>What you asked for:-

OK, the problems here are many.

The prime one is that, between the two queries, you are going round and
around the houses on the same piece of data: the PersonID of the person
who is represented by the PK of the left-hand table in your join, i.e. the
CoveredMem.PersonID is the *same* person who is joined to in both the
right-hand side of the join AND the lookup.

Secondly, you have named a KeyRelation (which tells IBO to update the
CoveredMem table) so any KeyLinks from the lookup set to a column in the
righthand side of the join wouldn't apply.

Third, despite what I explained about KeyDescLinks, you are still trying to
link the key field of the lookup set to the computed description field of
the parent set (notwithstanding the field named in the Keylinks is NOT
updatable anyway). KeyDescLinks links the Description field of the lookup
set to the "stand-in" computed field in the parent. So, if you had a valid
description field in your lookup set (which you don't) you would link that
to your LOOKUP_DESC field.

There isn't a valid description field in the lookup set because you don't
have any fields in the lookup set that match the computed field.

But all else pales beside the illogicality of three hits on exactly the
same piece of data, viz. in the join, the subselect and the lookup. Do you
see that you couldn't change or add a looked-up value to the dataset
because it's the join key for the set and changing it would violate the join?

It's impossible to guess what you're actually trying to achieve here, but
what you are doing is not logically achievable. If you want to get a value
from your person lookup for some undisclosed purpose, then don't use
Keysource binding here. Keep the Keysource and KeyLinks blank and just
pick up the selected value from the lookup dataset in your runtime code as
the value for the parameter you want to pass.

Helen