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.