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

    UB/circjob:circjob 43 doesn't decrement item.holds_placed

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

    Description:
    Bug Report Form for Issue 16384-12545

    Module(s): Circjob
    Server platform(s) affected: Solaris/all
    PC OS (if applicable): n/a
    Browser & version (if applicable): n/a
    Release(s): reported in 7.2.1; replicated in 7.2.2

    Expected results: When circjob 43 removes a row from ub_hold, it should also decrement the holds_placed counter for that item by 1.

    When circjob 43 removes a row from ub_hold, it doesn’t decrement item.holds_placed, so the item’s counter is now incorrect.

    Data like this exists as a result of Issue 16384-12529.

    Workflow implications: Confusing for operators who think there’s a hold, but there isn’t.

    Replication steps:
    1) Create two patrons in db A.
    2) Have each patron place a UB request on an item living in db B, for pickup in db A.
    3) In Call Slip in db B, process the first request for patron 1 – this starts a callslipsvr process at db A. The request processes normally and the expected rows are created in db A hold_recall and db B ub_hold.
    4) Kill the db A callslipsvr process.
    5) Go back to Call Slip in db B (still same session in Call Slip).
    6) Process the request for patron 2 – this time no callslipsvr process is launched, no row is created in db A’s hold_recall, and the ub_hold row created in db B erroneously has the hold_recall_id from #3 (these are the replication steps for creating the bad data from 16384-12529).
    7) Run circjob 43 at db A – you’ll see that the row is removed from ub_hold at db B, but item.holds_placed is still set to 1.

    Resolution:
    Fixed in circjob for 8.1.0.


    • Article last edited: 10/8/2013