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

Description:
Overdue notices were produced on 7/1/08 for items that were due (and returned) in 2007.

These same notices were again produced on 7/2/08 and 7/3/08.

Below is a list of patrons that were sent overdue notices for items that they checked out in 2007 and returned in 2007 . It seems that these items are once again checked out to these patrons.

Resolution:
Very odd. I find that there are 41 cases where there is a z36 record whose z36_number is the same as the z36h_number of a z36h record.

The z36/z36h_number is a unique ID assigned to each loan. There should *never* be a case where a z36 (active loan) has the same number as a z36 (loan history) record.

It seems that something is taking the z36h_record (which has a z36h_returned_date in 2007) and creating an active z36 from it (with a z36_returned_date of "00000000").

The SQL below shows these 41 cases. Please do the following:

1. Try deleting these 41 z36 loan records in GUI Circ. (I assume this is what you would want to do anyway, since they are not valid.) You may not be able to delete them since such a delete would try to create a z36h record with the same z36h_number as the existing z36h -- which Oracle, of course, will not permit. If you find you can't delete these, let me know and I will use SQL to delete them.

2. Run this SQL:

select z30_barcode, z30_rec_key from z30, z36, z36h where z36_number = z36h_number and z30_rec_key = z36_rec_key order by z30_barcode;

each evening, before the batch circ jobs are run. And again in the morning, after the jobs have run.

This will tell us two things: (1) If the the batch circ is generating these z36's -- which I very much doubt -- and, (2) when they *are* being generated.

Then, based on this information, we can try to determine *how* they are being generated.

[Subsequent runs of the SQL showed that no new cases were being created. No answer yet as to what caused this.... ]

• Article last edited: 10/8/2013