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

    Personal Copies have broken ADM Numbers; "Failed to find BIB-ADM relation"

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

    Description:
    I've just finished opening ABC31 on aleph1, following *exactly* the same steps used on the Test server. I can't see anything I did differently in this process, and I just double checked all relevant tables in alephe/tab, abc31/tab and abc30 tab. There are no significant / unaccounted for differences between the two environments.

    However, items created with the Circ Module's Catalog New button or "Create Bib and Item" menu option are disappearing.

    I've tested this with 6 items now, and all are having the same effect. I create the item, it appears to work fine, I push to cat with "Cat Item", and sometimes this step works and sometimes it doesn't. However, if I pull up the item by barcode in cat, I notice that the bib connection is severed. The error message reads: "Failed to find BIB-ADM relation". Returning to Circ at this point, the bib is still on the course, but the item is gone.

    In the most recent example, the reserves bib (ABC31 BIB 11) was initially created on ABC51 ADM 100226291, which is where the item lives.

    I push it to cat, and now I still have a BIB=11 ADM = 100226291, though I get the "Failed to find BIB-ADM relation" error.

    Now if I try to retrieve the item by BIB 11, it's ADM has shifted to 100226292...

    Retested to same results:
    - Created ABC31 Bib 14, with item barcoded 12321. Item and bib were created linked to ADM # 100226295.
    - Switched to Cat - got the same error message.
    - Pulled up item by barcode, still linked to ADM # 100226295
    - Pulled up bib by barcode, now linked to ADM # 100226297

    Resolution:
    This was resolved by running p_manage_12 for abc31, followed by p_manage_12 for abc51. In both cases the job was run with:

    p_delete_flag "Y"
    p_check_old "Y"

    Note: This should *not* be run with p_delete_flag "Y" in the case where the z103 count is not zero. (See below.)

    **Earlier Analysis (preceding p_manage_12 runs)**

    On Test we see this for abc51:

    abc51@ALEPH20> select z103_rec_key, z103_rec_key_1 from z103 where z103_rec_key_1 like 'ABC31%';
    **** Hit return to continue ****

    Z103_REC_KEY Z103_REC_KEY_1
    ---------------- --------------
    ABC5100333006102 ABC31000000001
    ABC5100333006202 ABC31000000007
    ABC5100333006302 ABC31000000009
    ABC5100000001802 ABC31000000018
    ABC5100000002002 ABC31000000020
    ABC5100000002402 ABC31000000024
    ABC5100000002602 ABC31000000026
    ABC5100000002902 ABC31000000029
    ABC5100000003102 ABC31000000031
    ABC5100000003702 ABC31000000037
    ABC5100000004102 ABC31000000041
    ABC5100000004302 ABC31000000043
    ABC5100000004602 ABC31000000046
    ABC5100000004902 ABC31000000049


    But on Prod, this for abc51:

    abc51@ALEPH20> select z103_rec_key, z103_rec_key_1 from z103 where z103_rec_key_1 like 'ABC31%';

    no rows selected


    But there *are* abc51 records on Prod which have LKR ABC31 fields:

    abc51 util f/4:

    Reading doc : 100226295
    ...
    LKR L $$aADM$$lABC31$$b000000015

    Reading doc: 000000017
    ...
    LKR L $$aADM$$lABC31$$b000000017

    Reading doc : 100226298
    ...
    LKR L $$aADM$$lABC31$$b000000017

    In fact, in *every* case the new abc51 ADM record is created correctly by Catalog New, but the z103 record is NOT written.

    I tested this by resending these ADM records to the server using util f/1/13. There was no error, but *no z103 was written*.


    • Article last edited: 10/8/2013