At 09:49 AM 06-09-02 +1000, you wrote:

>Ok, the query
>
> >SELECT GROUPS.GRP_DESCRIPTION,
> > SPRITEDETAIL.SD_DESCRIPTION,
> > SPRITEDETAIL.SD_CAMERA,
> > SPRITEDETAIL.SD_IPLOOKUPID,
> > IPLOOKUP.ID,
> > IPLOOKUP.IPL_DESCRIPTION,
> > IPLOOKUP.IPL_IPADDRESS,
> > IPLOOKUP.IPL_LOCAL
> >FROM SPRITEDETAIL
> > INNER JOIN GROUPS ON (SPRITEDETAIL.SD_GROUPID = GROUPS.ID)
> > INNER JOIN IPLOOKUP ON (SPRITEDETAIL.SD_IPLOOKUPID = IPLOOKUP.ID)
>
>has the MasterSource property connected to the datasource of the IPLOOKUP
>table (which is the table being browsed).
>
>I have changed the KeyLinks property to ID (being the unique field on the
>joined datasource).

Unfortunately no, IPLOOKUP.ID cannot be the unique key of this dataset
since, potentially, there will be multiple occurrences of it in the output
set, i.e. one for every row in SPRITEDETAIL that uses this
SD_IPLOOKUPID. A rule of thumb for analysing your unique key in a joined
set is the primary key of each underlying table. If you can't use those
because they are not in the set then you need to include (and use) as many
columns from the tables concerned as will provide that unique key ***for
the output set**.

In client/server work, especially where joins are involved, you have to
stop thinking "tables" and start thinking "sets". On the client side,
dataset objects represent (output) sets; on the server side, SQL operates
on sets and generates other sets.

>I just want to confirm this is correct because I get the same end result
>whether KeyLinks is:
>
>a) ID
>
>b) SD_IPLOOKUPID
>
>c) SD_IPLOOKUPID=ID
>
>Please say Yes!!! this time <trembling <g>>

This time I will say that you have been lucky - either the output rows in
your sample are fortuitously unique or you are not performing any operation
that needs the correct keylinks (including, most common of all, fetching a
fresh set of rows into the buffer).

(c) is either
1) a recent bug in IBO (dual keylinks outside the context of a
Keysource-Lookup relationship used to cause a dataset error..)
or
2) a recent "enhancement" in IBO where the parser deliberately ignores the
"=" sign and everything after it
or
3) a piece of luck for you insofar as IBO didn't need the keylinks for
anything you asked it to do in this example (my best guess).

Helen