Duplicate entry in old_reserves
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
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 <tmcmahon@wlpl.org>:
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 Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- *Hugo Agud - Orex Digital * *www.orex.es <http://www.orex.es>* <http://www.orex.es/> [image: www.orex.es/koha] <http://www.orex.es/koha> [image: www.orex.es/vufind] <http://www.orex.es/vufind> <http://www.orex.es/omeka> Director Calle Sant Joaquin,117, 2º-3ª · 08922 Santa Coloma de Gramanet - Tel: 933 856 138 hagud@orex.es · http://www.orex.es/ No imprima este mensaje a no ser que sea necesario. Una tonelada de papel implica la tala de 15 árboles y el consumo de 250.000 litros de agua. Aviso de confidencialidad Este mensaje contiene información que puede ser CONFIDENCIAL y/o de USO RESTRINGIDO. Si usted no es el receptor deseado del mensaje (ni está autorizado a recibirlo por el remitente), no está autorizado a copiar, reenviar o divulgar el mensaje o su contenido. Si ha recibido este mensaje por error, por favor, notifíquenoslo inmediatamente y bórrelo de su sistema.
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. 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 <tmcmahon@wlpl.org>:
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 Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Tim McMahon Technical Services West Liberty Public Library
On Tue, 31 Jan 2017 at 18:59 Tim McMahon <tmcmahon@wlpl.org> 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#... """ 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?...
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 <tmcmahon@wlpl.org>:
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 Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Tim McMahon Technical Services West Liberty Public Library _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
On 01/31/2017 12:37 PM, Jonathan Druart wrote:
On Tue, 31 Jan 2017 at 18:59 Tim McMahon <tmcmahon@wlpl.org> 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#... """ 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 <tmcmahon@wlpl.org>:
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 Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Tim McMahon Technical Services West Liberty Public Library _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Tim McMahon Technical Services West Liberty Public Library
We need to add ids to old_<tablenames> and have the original id be kept for historical purposes. As it is not reliable to use auto_increments on InnoDB the way we use them. "Switch to Postgres" is not a valid answer, please :-D El mar., 31 ene. 2017 a las 16:42, Tim McMahon (<tmcmahon@wlpl.org>) escribió: On 01/31/2017 12:37 PM, Jonathan Druart wrote:
On Tue, 31 Jan 2017 at 18:59 Tim McMahon <tmcmahon@wlpl.org> 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#...
""" 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.
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 <tmcmahon@wlpl.org>:
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
Thanks! packages
last Wednesday if that's any help.
-- Tim McMahon Technical Services West Liberty Public Library _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Tim McMahon Technical Services West Liberty Public Library _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Tim McMahon Technical Services West Liberty Public Library _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha -- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 <+54%209%20351%20351-3384> GPG: B2F3C15F
This is being discussed on bug 18003, please continue the discussion on the bug. On Tue, 31 Jan 2017 at 20:44 Tomas Cohen Arazi <tomascohen@gmail.com> wrote:
We need to add ids to old_<tablenames> and have the original id be kept for historical purposes. As it is not reliable to use auto_increments on InnoDB the way we use them.
"Switch to Postgres" is not a valid answer, please :-D
El mar., 31 ene. 2017 a las 16:42, Tim McMahon (<tmcmahon@wlpl.org>) escribió:
On 01/31/2017 12:37 PM, Jonathan Druart wrote:
On Tue, 31 Jan 2017 at 18:59 Tim McMahon <tmcmahon@wlpl.org> 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
""" If you specify an AUTO_INCREMENT column for an InnoDB table, the table handle in the InnoDB data dictionary contains a special counter called
https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html#... 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!
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 <tmcmahon@wlpl.org>:
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
On 01/31/2017 11:39 AM, Hugo Agud wrote: packages
last Wednesday if that's any help.
-- Tim McMahon Technical Services West Liberty Public Library _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Tim McMahon Technical Services West Liberty Public Library _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Tim McMahon Technical Services West Liberty Public Library _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
-- Tomás Cohen Arazi Theke Solutions (https://theke.io <http://theke.io/>) ✆ +54 9351 3513384 <+54%209%20351%20351-3384> <+54%209%20351%20351-3384> GPG: B2F3C15F _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz https://lists.katipo.co.nz/mailman/listinfo/koha
participants (4)
-
Hugo Agud -
Jonathan Druart -
Tim McMahon -
Tomas Cohen Arazi