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