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

    Restoring accidentally deleted patron records

    • Article Type: General
    • Product: Aleph

    Description:
    We have accidentally deleted patron records and need to restore them.

    Resolution:
    Patron records can be deleted: online, by p_file_20, or by the p_cir_23 (single ADM) / p_cir_77 (multi-ADM) GUI services.

    The deletion of a patron record always involves multiple record types. The p_cir_23 Help says:

    If the service is run with the option "All" in the "Sublibrary" filter, the following records are deleted: Z31, Z37, Z38, Z40, Z303, Z304, Z305 and Z308, as well as routing lists [z18].

    The best practice is to back up these tables with p_file_03 or a table-specific Oracle utility prior to running p_cir_23 or _77.

    The xxx50 $data_scratch/cir_23_del_01 file shows you what patrons (z303 records) have been deleted.

    The records can be restored in one of three ways:

    1) restore from a recent backup

    2) p_file_20

    3) copying from the Test instance with p_file_03 / p_file_04


    1) Restore from a recent backup: If you backed up the tables prior to the deletion, you can restore them with p_file_04 or an Oracle utility. If you have only a complete backup and can not easily extract the individual tables, the other options may be better.

    2) p_file_20 can give you up-to-date versions of the z303, z304, z305, and z308 tables. If all or most of the patrons were loaded via p_file_20, this may be an option. But you will not get any of the z31 (cash), z37 (hold request), z40 (ILL patron requests), or z18 (routing) records you deleted. The patron record numbers which Aleph assigns will almost certainly be different than the numbers the patrons had previously.

    3) Copying from the Test instance with p_file_03 / p_file_04 can get you all of the different record types. If you run p_file_04 with Procedure to Run "Append", records which already exist (in a, possibly, more up-to-date form) will get a "unique constraint violated" error and will not be loaded. But if the information in the Test instance is outdated, you may get hold requests which have already been filled, cash transactions which have already been paid, etc. This option should *always* be followed by p_file_20 to get the most up-to-date z303, z304, z305, and z308 info. Since the Aleph patron record will be created by the p_file_04, the Aleph record number will be the same as it was previously.

    Note: If you use SQL to update the z303, z305, or z308 records (not recommended in this case), you need to remember to run p_cir_25 to update the z353 Patron Index. (p_cir_23, p_cir_77, and p_file_04 all do this automatically.)


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