Greetings, I just hacked around it? https://github.com/mtompset/scripts/blob/master/innodb_hack.pl Yes, it’s hard coded and ugly, but it is semi-functional. And surely, there is a better way. Which is why I brought this issue up. [Smile] GPML, Mark Tompsett
From: Jesse<mailto:pianohac...@gmail.com> Sent: Monday, September 05, 2016 4:15 PM To: David Cook<mailto:dc...@prosentient.com.au> ; Mark Tompsett<mailto:mtomp...@hotmail.com> ; Owen Leonard<mailto:oleon...@myacpl.org> Cc: Koha-devel<mailto:koha-devel@lists.koha-community.org> Subject: Re: [Koha-devel] Serious problem Is there some sort of pragma or option we could set on the database or table to prevent this autooptimization? On Sun, Sep 4, 2016, 18:20 David Cook <dc...@prosentient.com.au<mailto:dc...@prosentient.com.au>> wrote: Glad to see someone else looking at this bug. We had this happen just the other day. Mark, I think the reset of auto_increment also happens after OPTIMIZE TABLE, if I recall correctly. Very annoying... Owen, you create a new entry in issues which gets an auto_id of 500. That bumps up the auto_increment to 501. However, if you move that entry into old_issues - with an id of 500 - then restart the MySQL server (it seems) or run OPTIMIZE TABLE issues, the auto_increment for issues is reset to 500. You try to check in that check out, and you get a software error, because there's already an entry with a primary key of 500 in the old_issues table. Not only is there a loss of history, but I'm pretty sure that newer issue stays in the issues table, because it can't be moved, and that'll likely have all sorts of flow on effects. Fun times! I noticed this happening for reserves as well last year or the year before I think. We've tried to mitigate it locally, since I don't really see a way of fixing this issue with the current Koha methodology of using deletedtables... David Cook Systems Librarian Prosentient Systems 72/330 Wattle St Ultimo, NSW 2007 Australia Office: 02 9212 0899 Direct: 02 8005 0595 > -----Original Message----- > From: > koha-devel-boun...@lists.koha-community.org<mailto:koha-devel-boun...@lists.koha-community.org> > [mailto:koha-devel-<mailto:koha-devel-> > boun...@lists.koha-community.org<mailto:boun...@lists.koha-community.org>] On > Behalf Of Mark Tompsett > Sent: Wednesday, 31 August 2016 11:42 PM > To: Owen Leonard <oleon...@myacpl.org<mailto:oleon...@myacpl.org>> > Cc: Koha-devel > <koha-devel@lists.koha-community.org<mailto:koha-devel@lists.koha-community.org>> > Subject: Re: [Koha-devel] Serious problem > > Greetings, > > >> check out, check in, restart mysql server, check out, check in... > >> old_issues bug! > > > What exactly is the bug? > > Loss of history. > Unless you do this after the server restart: > use koha_library; > insert into issues (borrowernumber) values (1); > -- this will fill the gap, and should restore it. > actually, whatever the mysql is to set the auto_increment to > max(issue_id)+1 from old_issues would work too. > > GPML, > Mark Tompsett > > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org<mailto:Koha-devel@lists.koha-community.org> > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ git : http://git.koha- > community.org/<http://community.org/> bugs : http://bugs.koha-community.org/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org<mailto:Koha-devel@lists.koha-community.org> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
