error trapping in select

[dcruncher4]

I have a condition in which I have to ignore an error while SELECTING.
The error is lock timeout (Db2 error code -911). When fetchrow_arrayref

fetches the locked row, I do get -911 which I trap in my code. When I
move on to the next row doing another fetchrow_arrayref, I get error -3
(no statement executing). Does that mean that fetchrow_arrayref
will stop processing at the first error and there is no way to continue
to the next stop, ignoring it.

DB2 gurus: Is there a way to tell DB2 while SELECTING to ignore rows
which are locked by another session.

thanks.

 

[Mark A]

I have a condition in which I have to ignore an error while SELECTING.
The error is lock timeout (Db2 error code -911). When fetchrow_arrayref

fetches the locked row, I do get -911 which I trap in my code. When I
move on to the next row doing another fetchrow_arrayref, I get error -3
(no statement executing). Does that mean that fetchrow_arrayref
will stop processing at the first error and there is no way to continue
to the next stop, ignoring it.

DB2 gurus: Is there a way to tell DB2 while SELECTING to ignore rows
which are locked by another session.

thanks.

You can append WITH UR on the end of the select to not take any locks, and
to ignore all locks taken by others.

There are some slightly less drastic measures that can be used to minimize
lock contention, but not completely eliminate it like you can by using WITH
UR.

 

[dcruncher4]

You can append WITH UR on the end of the select to not take any locks, and
to ignore all locks taken by others.

There are some slightly less drastic measures that can be used to minimize
lock contention, but not completely eliminate it like you can by using WITH
UR.

I am aware of this, but I can't use this if I end up with
a phantom row (that is a row which I read but
rolled back subsequently). That is a BIG no in my
case.

Is there a way to get an indication from DB2 that
I am reading an uncomitted row. If I can get that,
then I can store it for the time being and then
revisit later to double check.

 

[Mark A]

I am aware of this, but I can't use this if I end up with
a phantom row (that is a row which I read but
rolled back subsequently). That is a BIG no in my
case.

Is there a way to get an indication from DB2 that
I am reading an uncomitted row. If I can get that,
then I can store it for the time being and then
revisit later to double check.

I think you can use
SET CURRENT LOCK TIMEOUT 0
to immediately get -911 back if the row is locked, but to actually see the
data, you will need to issue another SELECT and use WITH UR.

 

[dcruncher4]

I think you can use
SET CURRENT LOCK TIMEOUT 0
to immediately get -911 back if the row is locked, but to actually see the
data, you will need to issue another SELECT and use WITH UR.

after -911 error fetchrow_arrayref stops further processing.