Created attachment 65146 [details]
From day before yesterday sometimes I have encountered an issue that when patrons return the books, the book does not check-in immediately. I tried a lot but every time it show the success message of check-in but still does not completely checked-in.
In Circulation log book is being checked-in, but at patrons page and OPAC it still shows book has been checked out by patron.
At staff login page when I try to see the book status it shows, book has been checked out as well as it is available.
I'm attaching some screen shot please help me as soon as possible.
Hi Anuj, can you specify the version of 16.11 you are using?
Can you also check issues and old_issues for entries of the book in question and maybe post the results?
Seen also on the mailing list: https://lists.katipo.co.nz/pipermail/koha/2017-September/049004.html
It seems that some checkouts has been moved to old_issues when checked in without a returndate. No idea how it is possible, neither which versions are impacted.
Please report and give information if you encountered this issue.
I've had it reported by two sites in the last few days they are running 16.11.08 and 17.05.01 looking at the latter case there are thousands of old_issues with a returndate set to NULL
Not sure if these comments help but…
This problem is a very serious one for us as from Wednesday 1 November absolutely zero lines in the old_issues table have the returndate field populated. And overall, we now have upwards of 20,000 items showing up in the Circulation History (both OPAC and Koha intranet) as “issued” when in reality they have long since been returned (including a period when we were on 16.05). This is very confusing for both staff and students. The problem appears to have got gradually worse over many months. I ran the simple query SELECT itemnumber, timestamp, returndate FROM old_issues WHERE timestamp > '2015-08-30%' ORDER BY timestamp ASC and browsed down for empty returndate fields. (UAL migrated 3 million lines of historic loans from out old LMS and want to review the problem from Day 1 of Koha only, hence the August 2015 limit).
At first I see a small number of problems appearing after the end of many of the day’s opening hours. Even back on 16.05 in June of this year we have transactions occurring in the middle of the night when the library is closed. I have no idea where these are coming from- the building is locked so users don’t have access even to the 3M returns chute (use of which would remove the item from the account). Oddly a lot of the lines are all timestamped in the 23:xx range and all are without a returndate.
The problem gets steadily worse as the weeks go by, and my take on it is that the problem explodes in 17.05.01 (8/2017 for us) where the count of the lines rockets. By the 4th October we are seeing upwards of 100 lines appearing, all timestamped in the 22:xx range, and all with no returndate. The library is closed at that time. And by 30th we have 1,205 lines with a timestamp (all now in *both* the 22:xx and 23:xx ranges) but no returndate, again at a time when the building is locked up for the night. The last line in the table with a returndate in is Tuesday 31 October at 21:55 when the library physically closed. Lines in the table are timestamped all through the (now 24 hour a day) opening time, but there are no return dates. We have currently 15,000 sequential lines without the returndate and this is making Circulation History a mess.
Would a crude fix be to copy the timestamp over the returndate where the return date is empty? I can of course add the 737,000 line spreadsheet containing the data I have reviewed if necessary.
University of the Arts London
As notes on this page: https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix and annonced for months now, the only safe versions are :
After 17.05.02, 16.11.10, 16.05.15 (included)
You should upgrade ASAP