Bad abc50 last-request-number, last-hold-group, & last-slip-number?

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Article Type: General
Product: Aleph
Product Version: 20

Description:
We've been experiencing a series of problems related to eTrust which monitors our Aleph 20 system, and one of the problems was that on Tuesday 2010-08-10 our ABC50.Z52 was dropped (or unavailable) and it was replaced by the USM50 version of the table.

When we realized what had happened we shut down the PC server and did a flashback to a time when we knew the correct table was in place.

We were able to identify the ADM records which were created during that time period and restore the correct bib links. While we were reusing ADM keys which had already been assigned, the existing ADM was being overwritten with a link to a newly created Bib record.

We were able to fix those records and the 1 patron record which was created at this time but I'm wondering if there are any implications for z36 (loans) or z31 (cash transactions). I'm also wondering which oracle tables are affected by the z52 counters for last-request-number, last-hold-group, and last-slip-number. There was probably about 1.5 hour of operation with the USM50.Z52 table in place, but I'm not sure if any of the records written as a result of circulation activity will have any consequences. The record keys for the cash transactions don't appear to be affected.

Resolution:
The last-request-number is used to assign the z37_request_number. As described in KB 5795, if the last-request-number is too low and the number has already been assigned to an existing request, the "unique constraint ...Z37_ID2 violated" message will be issued and no request is created.

The last-hold-group is used to assign the z37_group_id for requests that are part of a serial group. Multiple z37's share the same z37_group_id. It is possible that a number assigned to an existing group could be used for some other group, but unlikely. And it probably is not actually a problem.

The last-slip-number is printed on the hold slip by the ./form_fill/hold_request_slip_xml program. It could be that multiple hold slips could have had the same number printed on them. Not any significant problem.

Article last edited: 10/8/2013