first check would be key column after insert and update pattern...
perhaps log called in hook methods on record level of CRUD executing from CA

>>>Had a strange case... the scenario goes like this:
>>>
>>>

if not seek(...)
>>>    insert into ... (short field list, just keys) values (...)
>>>    tableupdate()
>>>endif
>>>...
>>>replace {four more fields}
>>>tableupdate()

>>>
>>>This was a fast job so I didn't really check the result of each tableupdate(); this is on cursoradapters, BTW. The weird thing is that in cases where the record was freshly inserted, the second tableupdate() didn't work. The quick and dirty solution was to run this twice, which worked so I didn't lose too much time on it (it had about 70000 records to create/update), but I'm just curious as to why would this happen at all.
>>>
>>>Did anyone have a horse of this color?
>>
>>Cursor buffering is tablebuffering ?
>
>Row buffering, but I'm sitting on the same record.
>
>>You say:
>>the second tableupdate() didn't work.
>>In what sense ?
>
>The changes aren't written to the SQL on newly inserted records, but are on the records which existed.
>
>I'll eventually catch the time to revisit this and check the error codes and whether the adapter tried to insert the same record twice or what.