Ann W. Harrison wrote:

>Ever since I heard of it, I've thought that a read
>committed, no wait transaction was an abomination
>in the sight of the concurrency gods.
>
>

I use nothing else.

>The effect is to cause the transaction to fail with
>an apparent deadlock if there are any uncommitted
>records in the data set examined.
>
>

Are you sure this isn't the behaviour when combined with another TR
option? In my experience, the effect is rather to fail immediately
(without waiting) if any other transaction tries to UPDATE a record
that's already been updated in a different transaction.

>Does anybody
>have any idea what it might possibly be good for?
>
>

I use it all the time. I know that theoretically, it's better to use
SnapShot and make short transactions, but that requires a different
programming approach. So instead, I use
CommitRetaining/RollbackRetaining all the time, with read-committed,
no-wait transactions. If a user tries to edit a record, I first perform
an empty update. That way, if another user is already editing it, they
immediately get an error message telling them so. As soon as the other
update is over (CommitRetaining), the record is again available for
modification. Using snapshot, I would have to close and restart my
transaction in order to be able to update the record.

>If you commit the transaction in the qli session and reissue the
>select in the isql window, it will succeed. Store another uncommitted
>record in the qli window and the next isql select fails.
>
>

I don't understand how you can get such an effect. Isn't this behaviour
specific to a combination with another option? Isn't there an option
that locks the record for both read and write access?

Regards,
Jonathan Neve.