Skip to main content
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