- Article Type: General
- Product: Aleph
- Product Version: 20
We discovered something new that started happening yesterday. Every night we update our patron database using a series of p_file_20 loads. We've been using this process since Aleph 15.5.
Starting with the Tuesday morning load the new patrons that are being created by this load are not getting system generated barcodes. This causes a problem when we try to update the patron, The following error is generated:
Error (b_file_20_chk_edit_record) : failed to find z308-key-type 01 for cur-id XXXNNNNNNNNN
If we insert a barcode with the load, everything is fine.
Up though Monday's load, everything worked fine. Tuesday was the first day there were problems.
In the output from the p_file_20 run, we see log lines indicating the barcode ID was created, like so:
System is adding z308 type 00.
System is adding z308 type 01.
But when I look at the corresponding line in the report generated by p_file_20, there is no indication of the barcode being generated, while before Tuesday there was.
I've been pouring over the system and I cannot find any tables that have been changed.
The only additional information I have is that there are a number(19) of Z308 records for barcodes that do have an empty Z308_ID field. In looking at our development server there are none. Now there happens to be 18 errors in the plif load this morning, so these plif errors might be generating the bad Z308 entries.
Is it possible that the other bad Z308 started this entire thing? Is there a way to figure out what record that Z308 was supposed to be linked to? Do you have any other ideas?
You should look for z308 type '00's which lack a type '01':
SQL> select z308_id from z308 where substr (z308_rec_key,1,2) = '00' minus select z308_id from z308 where substr (z308_rec_key,1,2) = '01';
and use the SQL INSERT command to create a z308 with z308_rec_key '01nnnnnnn' where 'nnnnnnn' would be the patron ID. That is, the type 00 would be '00nnnnnnn' and the type 01 would be '01nnnnnnn'.
[From site:] I've got the problem fixed. Thank you for your input.
What I ended up doing.
1. I was able to get a list of the z303_rec_key's using the following SQL. There might be a better SQL because it did take a while to run.
select z303_rec_key from z303 where z303_open_date in ('20110426', '20110427')
and z303_rec_key not in (select z308_id from z308 where z308_rec_key like '01%');
2. I wrote a perl script that read in these IDs and then did the following:
a: Check for the existence of a barcode (there shouldn't be one)
b: Retrieve the Z308 record for the Aleph ID
c: Modify the Z308_REC_KEY to make it a type 01 ID
d: Insert a new record using the new Z308_REC_KEY with the fields from the type 00
Of course I made a backup of the Z308 table before running the script. The script ran quickly and I was able to do it without any interruption of the system. The patrons were not retrievable to begin with.
I have no idea how the corrupted record (blank patron ID) came into existence. I tried to create one from the GUI client, but was not able to.
I did run the 18 records that erred off without a problem.
KB 16384-37074 describes a v20 rep_change which prevents z308s with blank z308_id's from being created.
- Article last edited: 10/8/2013