Skip to main content
ExLibris
  • Subscribe by RSS
  • Ex Libris Knowledge Center

    Cannot add new patrons: "Duplicate System ID".

    • 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