Helen,

Thanks for your comments.

I *have* a solution for TIB_Query.

It will work with IP grid connected to TIBOQuery if the sorting is done using a
number instead of a name.

You have mis-read my SELECT statement: it *does* JOIN B.ID with A.BID and not
B.ID to A.ID as you stated.

One of the problems with IBObjects is that that cutting and pasting the
IB_LookupCombo from outside the grid to inside the grid doesn't always work ---
very frustrating.

Helen Borrie wrote:

>
> Gerard J.M.Houtenbos wrote:
>
> > > >I tried a join-TIBOquery, but then the Captains.Name isn't
> > > >editable.
> > > >
> > > >I tried to use a TIBOquery with a lookupfield for the
> > > >Captains.Name, but then I can't index on the Captains.Name using
> > > >OrderingItems.
>
> At 04:57 PM 25/12/2002 +1030, Raymond Kennington wrote:
>
> >It's taken me 5 hours to work out how to do this.
> >
> >There are 2 major problems here, one with the GSG and the other with
> >IBObjects.
> >
> >1. This is because IBObjects Gettging Started Guide indicates that one should
> >use a singleton select for the looked-up item rather than a join, so to start
> >with, use a JOIN to get the looked-up item.
>
> Raymond, sorry to spoil your little moment, but the GSG is correct
> regarding the lookup mechanism that is implemented in the TIB_BDatasets. I
> think your confusion arises from trying to make TIB_LookupCombo work with
> the TDataset-compatible datasets. Gerard is using TIBOQuery and an
> Infopower grid.
>
> Gerard won't get the native ibo-like behaviour using TIBOQuery and your
> suggestion to use a join will get him fairly close. The crucial problem
> here is his desire to make the "lookup" field editable. There are ways to
> do that. However, he can still go the subquery route, if that works better
> for him.
>
> You wrote:
>
> >Let the SELECT statement be
> >
> >SELECT A.ID, A.Name, B.Name as CaptainName
> > FROM A JOIN B on (B.ID = A.BID)
> >
> >2. The Create button on the OrderingLinks page incorrectly produces:
> >
> > CaptainName=CaptainName; CaptainName DESC
> >and
> > CaptainName=Item=1
> >
> >whereas it should have produced
> >
> > CaptainName=B.Name; B.Name DESC
> >and
> > CaptainName=Item=1
>
> >The documentation and tool are letting us down here and that makes it very,
> >very, very difficult and frustrating.
>
> You still seem to have difficulties and frustration from not understanding
> the dependency between the IBO mechanisms and the metadata. OrderingLinks

If I do not understand it, it is because of the sheer paucity of information in
the GSG and Help and also the errors in the GSG and bugs in IBObjects.

> can't be set up to work automatically on non-database columns, such as your
> CaptainName example. The main problem here is that your example query
> doesn't extract enough output columns to maintain the necessary links

Wrong.

The main problem is that IBObjects should have recognised the lookup field and
produced an ORDER BY 3 instead of ORDER BY CaptainName

> (KeyLinks) to the underlying database columns. Provided the KeyLinks of
> the joined set were spot-on, you could get the OrderingLinks button to
> generate the "correct" mappings if your query were:

KeyLinks is A.ID and I set that myself.

>
> SELECT Players.P_Key, Players.Name,
> Captains.P_Key, Captains.Name
> FROM Players
> JOIN Captains
> ON Players.CaptainKey = Captains.P_Key
>
> Notice that the JOIN criterion here is different to that in your example
> (which is wrong, since it joins the two primary keys, instead of the
> foreign key and the primary key respectively).

Are you sure?

>
> The KeyLinks here would be:
>
> Players.P_Key
> Captains.P_Key

Why is the Captains PK required in the KeyLinks when there is only one captain
for each player?

Raymond.