Skip to main content
ExLibris

Knowledge Assistant

BETA
 
  • Subscribe by RSS
  • Back
    Aleph

     

    Ex Libris Knowledge Center
    1. Search site
      Go back to previous article
      1. Sign in
        • Sign in
        • Forgot password
    1. Home
    2. Aleph
    3. Knowledge Articles
    4. Bad abc50 last-request-number, last-hold-group, & last-slip-number?

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

    1. Last updated
    2. Save as PDF
    3. Share
      1. Share
      2. Tweet
      3. Share
    No headers
    • 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
    View article in the Exlibris Knowledge Center
    1. Back to top
      • backward_warning" in applying Service Pack
      • Bad gateway message in Web OPAC
    • Was this article helpful?

    Recommended articles

    1. Article type
      Topic
      Language
      English
      Product
      Aleph
    2. Tags
      1. 20
      2. contype:kba
      3. Prod:Aleph
      4. Type:General
    1. © Copyright 2025 Ex Libris Knowledge Center
    2. Powered by CXone Expert ®
    • Term of Use
    • Privacy Policy
    • Contact Us
    2025 Ex Libris. All rights reserved