At 12:05 PM 27/12/2002 +0100, you wrote:

> >The KeyLinks here would be:
> >
> >Players.P_Key
> >Captains.P_Key
> >
> >For the lookup dataset, your query would be
> >
> >Select P_Key, Name
> >from Captains
> >Order by Name
> >
> >Just use KeyLinksAutoDefine and Requestlive for this query.
>
>I suppose the Requestlive-setting is required for both the
>queries.

Hmm, it should work for the main query

>>>>>>>>>>> IF <<<<<<<<<<<<<<<<<<<<<<

1. The Keylinks are correct. If you remove Captains.P_Key they are not
correct...
AND
2. You set the KeyRelation to Players.

Instead of *removing* Captains.P_Key from the KeyLinks, you need to try
*adding* Players.CaptainKey. In this case you need to include the column
in your select query. Make certain you are using fully-qualified
identifiers throughout - in your SELECT and in all of the linker properties.

>If I put this to an InfoPower grid with the columns Players.Name
>and Captains.Name neither one is editable.
>
>When I set the KeyRelation property of the main-query to Players
>and remove the 'Captains.P_Key' from the KeyLinks-property, then
>the column Players.Name is editable.

That doesn't solve your problem, though. Removing that column from the
KeyLinks trashes your ability to implement the order linking. Try it with
the extra field in the output...you can set its Visible property false,
along with the two primary keys. Even though it could be argued as
"redundant" because the foreign key and the Captains.P_Key are equivalent,
they will both work to achieve what you want: to make the fields that
belong to the KeyRelation (Name and CaptainKey) updatable; and to provide
the necessary hook for the ordering operation to locate the Captains keys
in their own table.

RequestLive won't work if the KeyLinks are wrong.

> >If you are permitting the Captains data in the lookupcombo to be editable,
> >then you will have to do several things to make the main dataset
> >respond.
>I don't need to edit the Captains data, but I need to be able to
>change the captain for a player. So I use a TwwDbLookupCombo to
>let the user select another captain. In the OnChange-event of the
>Captains.Name column I need to set the Players.CaptainKey to the
>current Captains.P_Key (selected in the lookupcombo).
>
>After this the order is invalid so I have to refresh the query.

Correct.

>So far so good. But now the ordering-problem.
>Because the two queries both have a field NAME, setting
>OrderingItemNo results in an exception stating the ambiguous
>reference.
>Also the use of a different displayname doesn't solve this.
>NAME=NAME;NAME DESC
>C_NAME=C_NAME;C_NAME DESC
>
>Is the only solution to rename one of the fields in the database?

No, the following should solve it (provided Captains.Name has both
ascending and descending indexes). Because of the join and the duplicated
column names, use the full identifiers in the SELECT, not aliases, and
repeat the full identifiers in the linker properties. This should give the
IBO the best possible chance to resolve the various SQL sub-clauses without
ambiguity. e.g.

NAME=Captains.NAME; Captains.NAME DESC

Keep us posted with how you progress. It would be good if an experienced
IBO/IB/Infopower user would step up and provide you with some tips about
the control properties. At best, I'm flying blind, based only on knowledge
of how the VCL controls behave. Infopower surely has some better tricks.

Unfortunately, you picked the wrong week to anticipate "many eyes" on your
problem. I know of several of our experts who are away from their desks at
the moment...

regards,
Helen