Perfectly clear.

Thanks Vlad.

Calin Pirtea

From: Vlad Khorsun
 

Small correction, sorry

> When record is about to be updated (or deleted) Firebird first reads it and
> checks its transaction number against current transaction and its isolation mode.
> At this stage "update conflict" error message is possible.
>
> If current record version was created by currently committed transaction and
> current transaction also see it as committed then current transaction allowed to
> proceed.
>
> Than backversion is created and stored somewhere and new version is prepared
> in-memory.
>
> Than current version is fetched again to be replaced by just created new version.
>
> In the mean time another transaction could delete our record and commit. More,
> if our transaction is read-committed it don't prevent garbage collection from physically
> deleting our record. So, current version can't be fetched as it is not exists anymore.
> In this case "cannot update erased record" error is raised.
>
> For application it is almost the same as "update conflicts with concurrent update".

If record was deleted and garbage collected (i.e. physically deleted) than Firebird will
return "update conflicts with concurrent update". But if record was deleted and still not
garbage collected (and deleting transaction is committed) - in this case "cannot update
erased record" error is raised.

Hope its clear now,
Vlad