Thanks a lot!!

Allready implemented and in test - I hope this solves my problem.

regards,
Jens Dein

--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@t...>
wrote:

> At 07:47 AM 23/09/2004 +0000, you wrote:
>
> >Hi,
> >
> >I have a problem that has been bugging me for a while now. In my

main

> >transaction I use a Cuncurrency locking isolation. I try to make

sure

> >that changes are committed on a regular basis.
> >
> >Somehow my users a sometimes getting a deadlock situation on a pure
> >select statement (no updates, just read only) using Committed
> >isolation.
> >
> >How is that possible? I thought I shoulden't be getting a deadlock

on

> >a select statement - only on changes!!
>
> If your ReadCommitted transaction is configured with NO WAIT locking

and NO

> RECORD VERSION, then any older transaction that has an update

pending will

> cause a lock conflict (erroneously delivered to you as a deadlock

message)

> if your SELECT requests rows that, if committed by the other

transaction,

> would change state.
>
> >Hov do I eventaully resolve what caused the lock?
>
> To quote Ann Harrison, in response to a real-life problem yesterday,
> similar to your own:
> "If "record_version" is set, then the select procedure should be
> able to ignore uncommitted records."
>
> >PS.
> >Using FB 1.5 and IBObjects for connectivity - if that is of any
> >importance.
>
> Your tiReadCommitted transaction should be configured with either

LockWait

> True, or with LockWait false and RecVersion true.
>
> ./heLen