Skip to main content
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Record locked by another user

    • Article Type: General
    • Product: Aleph
    • Product Version: 20, 21, 22, 23

    A user is reporting "Record is locked by another user" occurring frequently. A truck of books is barcoded; book truck goes to a quality control checker; who checks the data (wanding in barcode, etc.) more than an hour later -- encounters "Record locked" .... A serials checkin person has a problem with a checkin record; hands it off to a supervisor; then goes on to do another record (and another and another); serials supervisor goes to look at the first checkin record two hours later -- the record is locked by another user.

    The user took a book which had been barcoded earlier this morning and tried to wand it in -- this time it worked. She took a serial title which was problematic 1/2 hour before and could not get to the record (Locked) [the checkin person had moved on multiple times to other records -- I had them check the serials module to be sure that the record was not open on any other tab; the checker does not open the cataloging module at all]

    I saw no errors in the pc_server log ... the pc_server_defaults have:
    setenv default_lock_period 300
    setenv doc_lock_period 1800
    setenv file_lock_period 9999

    One typically sees records like this in the vir01 z60 lock table:

    This SQL can be used to monitor locks for a particular record:
    > s+ vir01;
    SQL> select * from z60 where z60_rec_key like '%001234567%';
    <where "001234567" is the record key>

    To look for item locks:
    SQL> select * from z60 where substr (z60_rec_key,6,7) = 'PC-ITEM';

    To look for user locks:
    SQL> select * from z60 where substr (z60_rec_key,6,6) = 'PC-USR';

    Note: Lock records don't automatically disappear from the z60; they may be there but in an expired state. (The $alephe_root/pc_server_defaults doc_lock_period parameter determines when the lock expires.)   The util a/12 ("Drop lock tables") and clear_vir01 entirely clean out the lock tables.

    If you are certain that a particular lock record is incorrect or unneeded, you can delete it with SQL, like this:

    > s+ vir01 
    SQL> delete from z60 where z60_rec_key like '%002303721'; 


    The lock period which applies to non-doc records (such as, in this case, the item) is "default_lock_period" (in pc_server_defaults).
    The lock period which applies to doc records (such as, bib, authority, HOL, ADM, or Course Reserve) is "doc_lock_period" (in pc_server_defaults).
    See the Article "Lock periods in pc_server defaults" in regard to lock periods.

    Additional Information

    See the articles  " Bib record is locked "   and   Lock periods in pc_server defaults .

    In SF Case 00491835 where the customer was getting the "Record is locked by another user" along with 'Remote Service Error (c0203 update-chk 98)', they found that deleting the 856 field from the record solved the problem:  there was some defect in the 856 field which was causing the problem.


    • Article last edited: 10/8/2013