--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:

> I suppose you do have RequestLive true?

Yes.

> If so, it seems as though your KeyLinks are not able to uniquely
> identify an underlying row in the table you marked as KeyRelation.

No. I've traced into IBO's code, and it generates a correct update
statement, whether I have KeyLinksAutoDefine=TRUE or KeyLinks=table.id
(the primary key column for the table).

The problem is that IBO passes incorrect *value* for the search column
- a value of zero, instead of the actual value of the id field.

> Have you got an outer join there, with nulls falling into the
> Keylinks?

Outer join - yes, but KeyLinks point to a primary key column in the
left (outer) table, which always has a non-null value.

> Do you have enough elements in your KeyLinks to ensure uniqueness?

Yes.

> Show your SQL, KeyLinks and KeyRelation.

SQL:

SELECT acct.*, p.group_code
FROM acct
LEFT OUTER JOIN p_tree(1, 1, ''T'') p ON acct.id=p.obj_id

KeyLinks = acct.id (the primary key for table acct).
RequestLive = TRUE
PreparedEdits = FALSE

IBO correctly generates this update SQL:

UPDATE acct SET name=? WHERE acct.id=?

The problem is that the second value that IBO passes to the API call
is always zero, instead of the actual id. I've verified it for a row
with a known id (non-zero of course).

Also, if I use my own EditSQL with exactly the same SQL (UPDATE acct
SET name=:name WHERE id=:old_id) - it works just fine.

So I guess the problem isn't the SQL, it's with the value that IBO
passes to the API call when it auto-generates the update SQL.

Regards,

Eyal.