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. Cannot add new patrons: "Duplicate System ID".

    Cannot add new patrons: "Duplicate System ID".

    1. Last updated
    2. Save as PDF
    3. Share
      1. Share
      2. Tweet
      3. Share
    1. Additional Information
    • Article Type: General
    • Product: Aleph
    • Product Version: 18.01

    Description:
    We just upgraded our test server to v18. During our testing of the circulation module, we have discovered that we can not add a new patron using the fast registration with the Circulation GUI.

    The message displayed is "Duplicate System ID", but when doing a search for the ID that the system generated, it cannot find that ID unless putting leading zeros in front of it. May be leading zeros or a lack there of is causing a problem.

    Resolution:
    This message occurs when the system, using the UTIL-G-2 last-bor-id counter, tries to assign a patron ID but finds that it already exists for another patron.

    Looking at the abc50 usr_library, I see this:
    Sequence Name Value Suppress Type Prefix
    -------------------- --------- -------- ---- --------------------
    5. last-bor-id 17810 y S

    But there is already a Z308 with this key:

    enter start Z308 key (YYXXXXXXXXXXXXXXXXXXXX)
    0017810

    01 z308 \
    02 z308_rec_key \
    03 key_type ...............00
    03 key_data ...............17810
    03 user_library ...........ABC50
    02 z308_verification ........P16844
    02 z308_verification_type ...00
    02 z308_id ..................17810
    02 z308_status ..............AC
    02 z308_encryption ..........N
    new key = K, exit = Q, continue = RETURN

    And the next:

    01 z308 \
    02 z308_rec_key \
    03 key_type ...............00
    03 key_data ...............17811
    03 user_library ...........ABC50
    02 z308_verification ........P16845
    02 z308_verification_type ...00
    02 z308_id ..................17811
    02 z308_status ..............AC
    02 z308_encryption ..........N

    <Etc.>

    Note: There is no *z303* with the key 17810, but the system is checking the Z308, type '00', not the Z303. The z303_rec_key's and the z308 type '00's *should* match one-for-one, but we see that there are 16,638 z308 type '00's (out of 73,208) which do not have a corresponding z303:

    abc50@ALEPH1> select count(*) from z308 where substr (z308_rec_key,2,12) in (select substr (z308_rec_key,2,12) from z308 where z308_rec_key like '00%' minus select z303_rec_key from z303);

    COUNT(*)
    ----------
    16638

    v16 Production has, basically, the same situation. It would seem that at some point z303's were deleted (with SQL?) without corresponding deletes being made to the z308(?).

    The existence of these "orphaned" z308 type '00's is not necessarily a problem (it seems ajax v16 is, basically, working OK, right?), but we need to be able to set last-bor-id to a value which will not conflict with existing z308 type '00's.

    I find that the z303 (and z308) keys are a bit of a muddle.

    For instance, we have:

    02 z303_rec_key \
    03 id ........................1234
    02 z303_proxy_for_id ...........
    02 z303_primary_id .............
    02 z303_name_key ...............smith frances h 17
    02 z303_user_type ..............REG
    02 z303_user_library ...........ABC50
    02 z303_open_date ..............20040309
    02 z303_update_date ............20040309

    And also:

    02 z303_rec_key \
    03 id ........................000000001234
    02 z303_proxy_for_id ...........
    02 z303_primary_id .............
    02 z303_name_key ...............jones ardelia carolyn 00
    02 z303_user_type ..............REG
    02 z303_user_library ...........ABC50
    02 z303_open_date ..............19880705
    02 z303_update_date ............19880705

    I suggest two things:

    1. Change the abc50 last-bor-id from 17810 to 18866, which is what I find on Production.

    2. Add a prefix of "ID" to the last-bor-id.

    After these changes, the abc50 UTIL-G-2 should have this:

    Sequence Name Value Suppress Type Prefix
    -------------------- --------- -------- ---- --------------------

    5. last-bor-id 18866 y S ID

    This will assure that the new patron ID's don't duplicate existing ones.

    Note: when the actual upgrade is done, you should do the same update, but instead of "18866", use the value which you see at that time on the Production abc50 UTIL-G-2.

    Additional Information

    faq


    • Article last edited: 10/8/2013
    View article in the Exlibris Knowledge Center
    1. Back to top
      • Cannot access Web OPAC
      • Cannot add records to course; blanks in course number
    • Was this article helpful?

    Recommended articles

    1. Article type
      Topic
      Language
      English
      Product
      Aleph
    2. Tags
      1. 18.01
      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