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