>It's impossible to guess what you're actually trying to achieve here, but
>what you are doing is not logically achievable.

As you may recall,

>My intention is to allow a user to add to the COVEREDMEM table from within

a

>TIB_Grid. when the user enters an 'ID' in the Person's ID column, the
>associated TIB_LookupCombo control must drop down and do an incremental
>search for this ID(not PersonId - which is a gen value). If the value is
>matched, and the user... from here I believe I can handle the various.

Maybe I should explain again. All I want to use this TIB_LookupCombo for, is
to do an incremental search for this person in the person table, and if
found, insert the associated PERSONID of the Person Table into the PersonId
Field of the inserted record in the CoveredMem table. If not found(via the
NotInList event), then insert a new record into the Person table and add
this PersonId to CoveredMem.PersonId. I have the Person tables fields
editable because of the InsertSQL. This is all to be done via a TIB_Grid.

Thanks,
Dion.


-----Original Message-----
From: Helen Borrie [mailto:helebor@...]
Sent: Monday, September 16, 2002 5:53 PM
To: IBObjects@yahoogroups.com
Subject: RE: [IBO] TIB_LookupCombo - Join Tables - too ambitious??


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



___________________________________________________________________________
IB Objects - direct, complete, custom connectivity to Firebird or InterBase
without the need for BDE, ODBC or any other layer.
___________________________________________________________________________
http://www.ibobjects.com - your IBO community resource for Tech Info papers,
keyword-searchable FAQ, community code contributions and more !

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/