🚀 go-pugleaf

"T. van Rompaey" <tvrompaey@scabbouw.nlNOSPAM> wrote in message
news:3e032c57$1@newsgroups.borland.com...
> A deadlock is when a statement (i.e. UPDATE) locks for example row 1 and
> then tries to update row 2.
> In the mean time another user has locked and edited row 2 and now tries to
> update row 1.
>
> So, row 1 is locked by user 1 and row 2 is locked by user 2 who are now
both
> waiting for the other user to release the lock.

I didn't realize IB could detect this and generate an error. I guess this is
the isc_deadlock error.

>
> The situation in your last sentence will (in my option) not generate a
error
> because the second statement will wait till the records are release from
the
> lock and either 1) try to delete or update a row that already is deleted
(=
> no problem) or 2) update or delete a row that is updated which will not
> generate a database error but you should write your software to prevent
> this. (i.e. check how much rows are edited / deleted after the stament and
> compare this to what you expect)

From my understanding it will wait only if one uses "read_committed",
"no_rec_version", and "wait" transaction attributes or one uses
"consistency" and "wait", else an error is produced when the second
transaction attempts to delete or update the record before the first
transaction commits. I guess this error is the isc_lock_conflict.

Thanks. The two cases explain the different errors.