- Article Type: General
- Product: Aleph
- Product Version: 20
We've had cases of p_file_20 incorrectly overlaying patron records because the data in the (PLIF) input record match-key is incorrect. How can we guard against this?
Such cases are rare but, given their seriousness, we recommend the implementation of Aleph's secondary check for duplicates. This secondary check involves setting tab100 CHECK-UNIQUE-NAME-BIRTH=Y. (The default is "N".) When you try to create or load a patron record with the same name/birthdate (z303_name)/(z303_birth_date) as an existing patron, the system will issue an error message and not load the record.
If your records lack birthdates, we recommend adding them, to enable your use of this important feature.
(1) load the USER-REC-BIRTH-DATE's via p_file_20, then
(2) set tab100 CHECK-UNIQUE-NAME-BIRTH=Y.
You may have students who, initially, lack SSN's/ID's and you may find it necessary to assign these students "dummy" SSN's/ID's. The problem is that when a PLIF record is (later) generated for the patron with the actual SSN/ID it won't match on the "dummy" record which was created.
Or you may have records from multiple institutions and it is not your intention to prevent the patron from having a separate record for each.
CHECK-UNIQUE-NAME-BIRTH=Y won't be useful in such cases. See SKB 16384-30417 for SQL to locate duplicates if you don't have CHECK-UNIQUE-NAME-BIRTH=Y.
- Article last edited: 10/8/2013