On 2017-07-20 23:33, setysvar setysvar@... [firebird-support]
wrote:

> Den 20.07.2017 16:53, skrev fredff13@... [firebird-support]:
>
>> I used Delphi's FireDAC components and FireDAC Monitor program
>> which tracing issues with Firebird. I posted extracted data from
>> tracing file after user hit save button to save changes in address1
>> line - it's very simple transaction which failed in Firebird 3 and
>> has no problem under Firebird 2.1. I also used IBExpert to do the
>> same thing - set Address1 to some value and save it - it's works,
>> but not when I run application. I don't know what was changed in FB
>> 3 to break the working code. Obviously something new added to
>> environment but I don't know how to tune my program (connection
>> properties, table parameters or something else) to be able to save
>> data properly.
>>
>> Thanks, Fred
> Hi Fred!
>
> I don't know the FireDAC components, but I would expect the RDB$DB_KEY
> in "SELECT A.*, A.RDB$DB_KEY AS FD__DB_KEY FROM COMPANY A" to indicate
> that FireDAC didn't find any primary key. Are you certain that company
> ID is defined as primary key in this table? I doubt fields with unique
> indexes or unique constraints will be enough.
>
> Moreover, I'm puzzled that the UPDATE statement contains this many
> fields in the where clause when RDB$DB_KEY is one of them.

Given the update code, I'd guess it is doing a form of optimistic
concurrency by only updating if the record didn't change from when it
was retrieved by adding conditions for all 'old' values into where
clause.

Mark