p_file_20: incorrect "z308-rec-key belongs to other user" message
- Article Type: General
- Product: Aleph
- Product Version: 20
Description:
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)
<etc.>
Resolution:
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 ****
Z308_REC_KEY
---------------------------
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