At 04:22 PM 1/03/2004 +0000, you wrote:

>Hi!
>
>With IBObjects 4.3Aa I have the following problem. I have a TIB_Cursor
>with a SQL
>
>SELECT * FROM Table1 join Table2 on Table1.ID = Table2.ID
>WHERE Table1.ID = :pID

The query is ambiguous.

select table1.* from table1
join table2 on table1.id = table2.id

>I set the properties
>
>KeyRelation := 'Table1';
>KeyLinks.Add('Table1.ID')
>RequestLive := true;
>
>First I do
>
>IB_Cursor.Edit;
>IB_Cursor.FieldByName('Field1').AsString := 'NewValue';
>....
>
>When I want to post the cursor to the server I get the error:
>-510: Cursor not updatable
>
>When trace my SQL then I find the following update statement:
>
>UPDATE Table1
> SET Field1 = ? , Field2 = ? , Field3 = ?
>WHERE CURRENT OF C17162776976181598
>
>What is this C171....? Is that an RDB$Key?

Yes. IBO uses it when there are no valid keylinks.

>Anyone has an idea, what I'm doing wrong?

First, don't write ambiguous joins.
Second, don't use joins that should be WHERE criteria.

select table1.* from table1
where exists(
select table2.id from table2
where table2.id = table1.id

>By the way: I found the error a bit funny because first I didn't set
>KeyRelation and KeyLinks at all - then there was no error but the row
>in the database just got never updated in the database (but the value
>was in the buffer in TIB_Cursor on client side). After setting the
>properties "correctly" (as I thought....) I got an error...

All of the above. A joined set is not a naturally updatable set. If the
keylinks are correct and it is possible to target each row in one table
uniquely then you can use KeyRelation to signal that table. But
KeyRelation can't work if the query is ambiguous.

You can override IBO's automatic DML logic by using the xxxxxSQL properties.

NB. If you were using Firebird 1.5 instead of IB 6, you wouldn't have been
able to submit your query...

Helen