> The problem is that the read_committed transaction will fail if it
> tries to update a record version created by a concurrent transaction,
> even if that transaction has committed. It's kinda dumb, but that's
> the way it's implemented. Read-committed transactions follow the same
> update concurrency rules as consistent read transaction. Even though a
> read-committed transaction can read a record version that was created
> and committed by a concurrent transaction, it can can't update that
> version.

Thanks for this very good explanation

>
> I stand by my preference for concurrency as an isolation mode.
>

but it's seam that the probleme is even worse with concurency than with isc_tpb_read_committed

i just do this try :
isc_tpb_read_committed
isc_tpb_no_rec_version
isc_tpb_wait

client 1 update rec 'xxx' set label ='xxx'
client 2 update rec 'xxx' set label ='www' => but the app freeze waiting client 1 commit
client 1 commit => OK
client 2 => OK => commit => OK

now with
isc_tpb_write
isc_tpb_concurrency

client 1 update rec 'xxx' set label ='xxx'
client 2 update rec 'xxx' set label ='www' => but the app freeze waiting client 1 commit
client 1 commit => OK
client 2 => DEADLOCK ERROR !


so how i can do to do my massive update ?
the isc_tpb_read_committed + isc_tpb_no_rec_version + isc_tpb_wait was the perfect solution (simply wait that transaction commit and update the last commited items) but now as you say it's not really the case i m lost :( does it's mean it's not possible to do any massive update on multi user table with firebird ?