--- In firebird-support@yahoogroups.com, Jakub Hegenbart
<Kyosuke@s...> wrote:

> 1) If there's a newer and uncommitted version of a row, NO OTHER
> TRANSACTION REGARDLESS OF ITS ISOLATION LEVEL is allowed to either
> update or remove the row

Yes

>and it doesn't even see it, although it may

(or

> may not, this depends on the I. L.) see it for SELECTs; and...

Read_commited rec_version will see last commited version.
Read_commited no_rec_version will return lock conflict even on read
attempt.
Concurrency will see record in the state which was last commited at
this concurrency transaction start moment even if record was changed
and commited 100 times since that moment.

> 2) Having said that, it's a feature intended for as least frequent

usage

> as it can be.
>
> Am I right?

Yes. I tried to show known reasons to use it and give all warnings
in mentioned article.

> A possibly stupid question: What if there were more rows to be

updated?

Nothing good in general :) But _sometimes_ we are forced to
implement crazy solutions. Maintenance (not structural but attributes
values) of damaged data with presence of users, for example. Look
article ;)

> Does SFUWL work even for SELECTs that aren't 'a part of a cursor
> construction?' (sorry, can't come up with a better name...) I mean,

does

> it lock the records with creating a new version without firing

triggers

> even when called per se, outside SP, for example? (So that the rest

of

> the transaction can safely crunch the data and update it after a

while

> without risking lost CPU cycles and still without resorting to

SNAPSHOT

> TABLE STABILITY or RESERVING ... FOR PROTECTED WRITE which would be

an

> overkill for updating few rows)

Yes.

Best regards,
Alrxander.