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

    Patron list not properly limiting when Display Local Patrons Only is checked

    • Article Type: General
    • Product: Aleph
    • Product Version: 19.01

    Description:
    The ADM we are working with is SVD50.

    There are some patrons that have been loaded via PLIF that are not showing up in the Patron List when "Display Local Patrons Only" is checked. Input files for the PLIF have been examined and no difference between patrons can be seen. It's more common when the patron has an initial barcode starting with SWQPL; but most SWQPL patrons display without issue.

    One patron that has problems is Alison Jones. This patron that started out in SWQ50 and now is part of the SVD50 load (p_file_20).

    Resolution:
    As described in KB 5813, the failure of patrons to appear in the "Display Local Patrons Only" list has to do with the z353. The following SQL shows the z353's for patron SWQPL11318:

    SQL> select z353_rec_key from z353 where z353_id = 'SWQPL11318';
    **** Hit return to continue ****

    Z353_REC_KEY
    -----------------------------------------------------------------
    SVD50 ID SWQPL11318
    SVD50 BC 20109001492334
    SVD50 NAME smith alison marie SWQPL11318
    SWQ50 ID SWQPL11318
    SWQ50 BC 20109001492334
    SWQ50 NAME jones alison marie SWQPL11318
    ID SWQPL11318
    BC 20109001492334
    NAME jones alison marie SWQPL11318

    You will note that the "SVD50 NAME" entry has the last name "smith" rather than "jones".

    The $usr_library Z303 for patron SWQPL11318 has the name "Jones". It seems that the patron had the name "Smith", was married, changing her name to "Jones", and the load of the patron as an SWQ50 patron, did not result in a change of the "SVD50 NAME smith" z353.

    We found that bringing up the Global Patron record, making an inconsequential change, and clicking on "Update", resulted in the correction of the z353 "SVD50 NAME" entry.

    I did some SQL to locate other discrepancies between the Z353-KEY-DATA and the Z303-NAME-KEY where the Z353-KEY=TYPE = "NAME", but this was getting too many cases where the only difference is a middle initial vs. the full middle name.

    I changed it to look for cases where the first three characters of the last name are different. There are 1,596 of those:

    SQL> select count(*) from z303, z353 where z303_rec_key = z353_id and substr(z353_rec_key,11,4) = 'NAME' and substr(z353_rec_key,16,3) ^= substr (z303_name_key,1,3);
    **** Hit return to continue ****

    COUNT(*)
    ----------
    1596

    The individual cases can be listed using the following SQL:

    SQL> select z303_name_key, z353_rec_key from z303, z353 where z303_rec_key = z353_id and substr(z353_rec_key,11,4) = 'NAME' and substr(z353_rec_key,16,3) ^= substr (z303_name_key,1,3) order by z303_name_key;

    But these are too many to update individually. I suggest that you run p_cir_25 for each of your ADM libraries. In sequence, with the first one with "Y" for "Delete All" and the others with "N". This will regenerate the z353 and put it in synch with the z303. (KB 16384-19810 describes a method for running p_cir_25 at a multi-ADM site.)


    • Article last edited: 10/8/2013
    • Was this article helpful?