Hi Helen

Thank you again for your reply

> >Okay, I also thought about the problem, that KeyLinks cannot be
> >resolved properly, because of field id, which isn't unique. So I used
> >another version of this query:
> >
> >select Table2.Field21, Table2.Field22, Table1.*
> >from table1 join table2 .....
> >
> >Field21 and Field22 are unique within Table1.
> >

Sorry, here I wanted to write something else: Field21 and Field22 are
unique as fields in Table2, I meant there is no field21 and field22 in
Table1.

> >Setting KeyLinks and KeyRelation as described in the mail before. But
> >this was still not helping to resolve the KeyLinks correct.
>
> No, the Keylinks won't be correct unless you provide the correct

Keylinks.

> :-) For this query, as a minimum (for uniqueness), you would need:
> Table2.Field21
> Table2.Field22
> Table1.ID

ID is primary key of Table1 and Table2. It's a (0,1):1 relationship
between the two tables. So ID alone gives back a unique key. When I
trace the SQL, IBObjects recognizes everything correct, I mean it
builds the Update-Statement correct also by using the correct KeyLink,
just the value of the KeyLink is not set.

Do you know how IBObjects is buiding the Edit-SQL? I can imagine two ways:

a) Because Table1 is the KeyRelation it checks up in the metadata
which field is the primary key for Table1 (for a serached update as
I'm doing now). Then it tries to find the fields in the dataset which
fit with the primary keys. But then I guess it won't need the
KeyLinks-Setting.

b) So I guess it's rather like this: IBObjects builds an
Edit-Statement for the KeyRelation and uses all KeyLinks-Fields which
belong to the KeyRelation. As the KeyRelation must always be the child
table in a join, KeyLink-Fields must always be unique for the child.
But then I don't see why it can't match my KeyLink-Field with my Field
in the Dataset.

So still I don't really understand why it's not working.

Sorry to bother you again!

Cheers
Daniel Achermann