Error 263 (ISAM 107) - Can not lock row for update

When I get this error -263, is there a way to know who locks the row and which row is? TIA & Happy NewYear Randy

Randy Hao wrote: > > When I get this error -263, is there a way to know who locks the row and > which row is? Yes but it ain't straight forward ( and if the table is fragmented this gets too complex to be worth the effort BTW). Get the partnum of the table in hex (SELECT hex(partnum) FROM systables where tabname = ...), get the ROWID of the locked row, run onstat -k and look for the PARTNUM and ROWID in the tblsnum and rowid columns, get the value in the owner column, run onstat -u and search for the owner value in the address (first) column, take the sessid value and run onstat -d <sessid>. OK now you know the user, pid, tty, hostname, etc. BTW the best solution is to take the advice given in the finderr message and SET LOCK MODE TO WAIT <Nseconds> in your application so that instantaneouslocks to not cause failures. Art S. Kagel

Art S. Kagel <kagel@bloomberg.net> schrieb in im Newsbeitrag: 386BB553.2567E99F@bloomberg.net... > Randy Hao wrote: > > > > When I get this error -263, is there a way to know who locks the row and > > which row is? > > Yes but it ain't straight forward ( and if the table is fragmented this gets > too complex to be worth the effort BTW). Get the partnum of the table in > hex (SELECT hex(partnum) FROM systables where tabname = ...), get the ROWID > of the locked row, run onstat -k and look for the PARTNUM and ROWID in the > tblsnum and rowid columns, get the value in the owner column, run onstat -u > and search for the owner value in the address (first) column, take the > sessid value and run onstat -d <sessid>. OK now you know the user, pid, > tty, hostname, etc. > > BTW the best solution is to take the advice given in the finderr message and > SET LOCK MODE TO WAIT <Nseconds> in your application so that instantaneous> locks to not cause failures. > > Art S. Kagel We had the situation that a user process locked a table/a row for a long time. SET LOCK MODE TO WAIT will not help in such situation. Other users calledthe DBA complainig they could not work any more. To find the locking (blocking) session and those jammed I use following little script: lock.sh exec dbaccess sysmaster - <<eof 2>/dev/null select dbsname,tabname,type,owner,waiter,username,pid from syslocks a, syssessions b where a.owner = b.sid and type <> "S";eof When found the session can be killed with onmode -z sid. Reinhard