RE: Dealing with Record locks in embedded SQL

Thanks Rob.

Both methods are a bit more complicated than using plain old RPG do loop.

The problem I'm facing is that every now and then developer will receive some 
miscellaneous user requests to mass update some records.  If not because of the 
record lock issue, those requests can easily handle by using plain sql UPDATE 
statement.  oh, well.  I guess writing a RPG program is the way to go.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of rob@xxxxxxxxx
Sent: Thursday, August 04, 2005 12:35 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: Dealing with Record locks in embedded SQL


There are a couple of different ways to handle this.  One is to check the 
SQLSTT and then dive into the joblog.
STRSQL 
Record 1 in use by job 888883/ROB/ROBS1. 
Record 1 in use by job 888883/ROB/ROBS1. 
Row or object LOCKER in ROB type *FILE in use.

It does stop at the locked record and does not continue on.  Records up to 
the locked record will be updated.  (Just finished some extensive testing 
on this.)  I did not mess with any isolation clause.

The other is to break your set-at-a-time update into a cursor (update 
where current of cur1).  That would give you more granularity, and, could 
be set up to skip the locked row (or unlock the row by cancelling the 
locking job) and finish updating the rest.


Rob Berendt