Skip to main content
ExLibris
  • Subscribe by RSS
  • ExLibris Dev

    UB:home patron UB counters need to be resynched with stub data

    • Article Type: General
    • Product: Voyager
    • Product Version: 6.2

    Description:
    Issue 19297

    UB:home patron UB counters need to be resynched with stub data

    The problem:
    We're seeing large numbers of cases in which the data in the home patron's UB counters (current_charges_ub, historical_charges_ub, requests_ub,
    historical_requests_ub, claims_return_ub, lost_items_ub, total_fees_due_ub, self_shelved_ub, total_demerits_due_ub in the patron table) does not
    match the data in the home patron's ub_charge, ub_charge_archive, ub_request, ub_request_archive, or ub_fine_fee tables. The data in any of the
    above tables (as well as the ub_patron_record table in the home database) also does not necessarily match the data in the holding database's call_slip,
    ub_hold, fine_fee, circ_transactions and circ_trans_archive tables, or the pickup database's hold_recall or hold_recall_archive tables.

    The discrepancies vary greatly by patron -- in some cases, the ub_charge counters are negative, in some cases the requests_ub counter will reflect
    hundreds of requests while the ub_request table will only reflect 10 or 20 active requests across UBland for this patron (requests that may or may not
    actually still exist in the stub patron's database; a number of these patrons have rows in ub_request dating back to 2003 or 2004), and in some cases
    the total_fees_due_ub in the patron record will not be an accurate total of this patron's rows in ub_fine_fee (which in turn might have current balances
    that are no longer reflected in the holding db's fine_tee table). In still other cases, rows that exist in the home db's ub_patron_record table no longer
    have corresponding stub records in the remote database specified.

    Workflow implications:
    The most frequent practical implication of this is that patrons pass fine/charge/request limits and become blocked from further transactions because their
    counters are reporting inaccurate totals. While the historical counters can be reset, current counters cannot, which means that the only way to prevent these
    patrons from being incorrectly blocked is to set the block limits very high or to eliminate them completely. If there are extraneous rows in ub_patron_record,
    a patron that should otherwise be eligible for deletion may not be deleteable.

    Reproduceable?:

    Testing internally on 6.2 with newly created patrons appears to increment counters/tables correctly. Sites who are reporting the problem also note that
    new patrons seem to be tracking accurately (so far, at least), and that frequently the patrons who are experiencing the data problems seem to be heavy
    UB users and typically have existed across several releases.

    Request:
    We would like a script that could resynch a patron's UB counters and data across UBland, specifically . . .
    The home patron's:
    ub_patron_record
    ub_charge
    ub_charge_archive
    ub_request
    ub_request_archive
    ub_fine_fee
    patron (columns current_charges_ub, historical_charges_ub, requests_ub, historical_requests_ub, claims_return_ub, lost_items_ub, total_fees_due_ub,
    self_shelved_ub, total_demerits_due_ub)

    The holding library's:
    call_slip
    ub_hold
    fine_fee
    circ_transactions
    circ_trans_archive
    The pickup database's:
    hold_recall
    hold_recall_archive

    Resolution:
    Fixed in Voyager 7.0.1 and beyond with circjob -j43.


    • Article last edited: 10/8/2013
    //doorbell.io feedback widged