|Subject||Re: [firebird-support] Foreign Key implementation|
> I can perfectly understand this behaviour if transaction 1 modifiedSecond transaction have no knowledge which fields was changed by
> the emp_no field, but I can not see why it is necessary for an update
> of an unrelated field.
1st transaction so it must wait for stable master record version.
> Is this an implementation limitation in Firebird or a deliberate design choice?I'd said it is implementation details. Not looked what standard say
> If it is a design choice, then what is the reason?
> Why would an update on the child table ok but an insert disallowed?Because this update is not changed FK fields while insert does. So
no needs to check FK in this case
> Why would it be OK if the child row was updated before the insert is run?Because in this case master record is not changed by currently active
transaction and considered stable.
> If it is an implementation limitation, is itYou may add it to the tracker of course but do not expet quick fix
> fixed, planned to be fixed, or should I add it to the tracker?