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

    p_file_20: incorrect "z308-rec-key belongs to other user" message

    • Article Type: General
    • Product: Aleph
    • Product Version: 20

    We are seeking assitance with resolving errors in the Plif run in our PROD region.

    We have tried deleting the faulty patrons using both cir-23 and Patron Delete but when the Plif is re-run the errors return.

    The Plif runs successfully in our TEST region.

    Attached is a copy of today's errors:

    When the plif file is uploaded, some records are being created with a “B” barcode instead of the ABC ID (numeric). See examples below. In trying to resolve this problem, the records with the “B” barcode were deleted and the plif reloaded. In some cases, no record is created for the patrons who previously had “B” barcodes. In other cases, the record is created with the same “B” barcode. In order to facilitate loans to some of these patrons, we manually created records for them.
    Checks were carried out on the plif error “z308-rec-key belongs to other user”. We disovered that the other user being referred to is the same individual. In the prod region, the issue with the “B” barcode exists. However, the same patrons, loaded vis the same plif file in the test region were succesfully loaded and recrds were created with the ABC ID and there were no errors.

    Patron – James Smith
    Error (b_file_20_chk_edit_record) :
    Record No 000724
    z308-rec-key belongs to other user (012807003239 ABC50)


    The message "z308-rec-key belongs to other user (012807003239 ABC50)" indicates that p_file_20 is trying to insert a z308 type 01 with the value "2807003239", and that some other patron has a z308_rec_key with this value.

    I did the following SQL to locate that patron:

    abc50@ALEPH20> select z308_rec_key, z308_id from z308 where z308_rec_key like '012806002591%';
    **** Hit return to continue ****

    Z308_REC_KEY Z308_ID
    --------------------------- ------------
    012806002591 STA50

    You will note that the z308_id is blank -- which makes it, by definition, a defective record.

    Then I did the following SQL to locate other such cases:

    abc50@ALEPH20> select z308_rec_key from z308 where z308_id like ' %';
    **** Hit return to continue ****

    012605718708 ABC50
    012806001448 ABC50
    012806003130 ABC50
    0191805030 ABC50
    012605765088 ABC50
    012806000126 ABC50
    012807003269 ABC50
    012686847500 ABC50
    012601716414 ABC50
    0193710123 ABC50
    012807003239 ABC50
    01809000604 ABC50
    012605701498 ABC50
    012806002591 ABC50
    012605727188 ABC50
    012806001644 ABC50
    012806002247 ABC50
    012806006996 ABC50
    012806007312 ABC50
    012806008171 ABC50
    012807003503 ABC50
    012807005680 ABC50
    0186983780 ABC50
    012697719272 ABC50
    012699733123 ABC50
    012603772129 ABC50
    012604742087 ABC50
    012603727758 ABC50
    012605766355 ABC50
    012600722222 ABC50

    (There are 30.) I suspect that these correspond to your problem patrons. These defective records need to be deleted (via SQL, since you will not be able to bring up such a defective record in the GUI).

    You should back up the z308 table with p_file_03 before making any such update.

    I don't know what might have caused this, but KB 16384-30387 is a somewhat similar case in which deleting the problem z308's corrected the problem.

    KB 16384-37074 describes v20 rep_change 3520 which prevents z308s with blank z308_id's from being created.

    • Article last edited: 10/8/2013