--- "Ann W. Harrison" <aharrison@...> wrote:

>
> At 12:36 PM 9/21/2004, Jonathan Neve wrote:
>
> > >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?
>
> Yes, I'm quite certain that if a read committed no wait transaction
> encounters a record that has been written (inserted, updated, or deleted)
> and not committed it will get an immediate deadlock error, whether
> the transaction that did the write is read committed, snapshot,
> wait, or no wait.
>
> > 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.
>
> It demonstrably fails with ISQL when attempting to read an
> uncommitted record.
>

The answer to this confusion is the "Rec_Version" flag. In IBExpress, if you
click on the "Read Committed" radio button, you get read_committed,
rec_version, and nowait flags. The IB6 API Guide says

IMPORTANTThe combination of the options
isc_tpb_read_commited,
isc_tpb_no_rec_version, and
isc_tpb_nowait
will cause frequent deadlocks. This combination is not recommended.

But it also says, where it defines "isc_tpb_rec_version", that it

Enables an isc_tpb_read_committed transaction to read the most recently
committed version of a record even if other, uncommitted versions are pending.

In other words, use rec_version, and you can read the most recent stuff, even
if there are uncommitted changes- just as Jonathan says- but if you use
no_rec_version, then you'll get a deadlock in that situation- just like Ann
says.