On 2017-07-20 23:33, setysvar [email protected] [firebird-support] wrote: > Den 20.07.2017 16:53, skrev [email protected] [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
