On 01/31/2017 12:37 PM, Jonathan Druart wrote:
On Tue, 31 Jan 2017 at 18:59 Tim McMahon <[email protected]> wrote:

Thanks for the quick reply.  We've been on Koha since 2006 and the item
in question was fairly new, so that wouldn't be it.  I agree, the
auto-incremement on the reserves key should keep this problem from
happening.


Unfortunately, not at all.
From
https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html#innodb-auto-increment-initialization
"""
If you specify an AUTO_INCREMENT column for an InnoDB table, the table
handle in the InnoDB data dictionary contains a special counter called the
auto-increment counter that is used in assigning new values for the column.
This counter is stored only in main memory, not on disk.
"""

That means you can get twice the same number if you restart mysql.
Bug or feature?...



I don't remember restarting MySQL recently, but that doesn't mean for sure that I didn't. I'm willing to say that it could happen again and just hope it doesn't. The conflicting reserve_id was from reserves placed days apart with a few reserves placed between, so that doesn't look like it would be the cause.

Thanks!

On 01/31/2017 11:39 AM, Hugo Agud wrote:
Hi

We have seen this when we have migrated data from another ils, the issue
has an auto-incremental id, but old_issues copy the id from the issues, I
guess that perhaps it is the same with reserves and old_reserves.

then the question is, have you migrated koha from another ILS and you
have
migrated historical data on reserves? If yes.. that it should be the
answer

2017-01-31 18:16 GMT+01:00 Tim McMahon <[email protected]>:

I got an internal server error while checking out a reserved item to a
patron.

The plack-error.log showed this error:

DBD::mysql::st execute failed: Duplicate entry '4515' for key 'PRIMARY'
[for Statement "INSERT INTO `old_reserves` ( `biblionumber`,
`borrowernumber`, `branchcode`, `cancellationdate`, `expirationdate`,
`found`, `itemnumber`, `itemtype`, `lowestPriority`, `notificationdate`,
`priority`, `reminderdate`, `reserve_id`, `reservedate`, `reservenotes`,
`suspend`, `suspend_until`, `timestamp`, `waitingdate`) VALUES ( ?, ?,
?,
?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ? )" with ParamValues:
0='4095', 1='4310', 2='WLPL', 3=undef, 4=undef, 5='F', 6='4177',
7=undef,
8='0', 9=undef, 10=0, 11=undef, 12='4515', 13='2017-01-26', 14='',
15='0',
16=undef, 17='2017-01-26 14:05:25', 18='2017-01-26'] at
/usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1832.
DBIx::Class::Storage::DBI::_dbh_execute(): Duplicate entry '4515' for
key
'PRIMARY' at /usr/share/koha/lib/Koha/Object.pm line 120

I checked in the old_reserves table and found that there was already an
entry with a reserve_id of 4515.

Does anyone know how this would happen?

I'm running Koha 16.11.20.000 on Debian 8 and just updated from packages
last Wednesday if that's any help.

--
Tim McMahon
Technical Services
West Liberty Public Library
_______________________________________________
Koha mailing list  http://koha-community.org
[email protected]
https://lists.katipo.co.nz/mailman/listinfo/koha





--
Tim McMahon
Technical Services
West Liberty Public Library
_______________________________________________
Koha mailing list  http://koha-community.org
[email protected]
https://lists.katipo.co.nz/mailman/listinfo/koha

_______________________________________________
Koha mailing list  http://koha-community.org
[email protected]
https://lists.katipo.co.nz/mailman/listinfo/koha


--
Tim McMahon
Technical Services
West Liberty Public Library
_______________________________________________
Koha mailing list  http://koha-community.org
[email protected]
https://lists.katipo.co.nz/mailman/listinfo/koha

Reply via email to