- Article Type: General
- Product: Voyager
- Product Version: 7.2.1
Bug Report Form for Issue 16384-12545
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.
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.
Fixed in circjob for 8.1.0.
- Article last edited: 10/8/2013