[Koha] Salvaging data before using DBMS auto increment fix
Pedro Amorim
pjamorim91 at gmail.com
Tue Oct 24 03:34:22 NZDT 2017
Thanks for your reply, Marcel.
I'll probably go for option number 2 given the size of the data, it's safer
and I'm happy with it.
Thanks a bunch, have a good one.
Pedro Amorim
2017-10-23 12:46 GMT+00:00 Marcel de Rooy <M.de.Rooy at rijksmuseum.nl>:
> Hmm. You need to have room in the deleted range to do that of course..
>
> -----Oorspronkelijk bericht-----
> Van: Koha [mailto:koha-bounces at lists.katipo.co.nz] Namens Marcel de Rooy
> Verzonden: maandag 23 oktober 2017 14:43
> Aan: Koha list <koha at lists.katipo.co.nz>
> Onderwerp: Re: [Koha] Salvaging data before using DBMS auto increment fix
>
> [This sender failed our fraud detection checks and may not be who they
> appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]
>
> Pedro,
> Personally I would delete the 19 old ones. Your option 2. Easiest, no big
> data loss..
> In contrast with your option 3 you could also renumber the 19 old issues
> in the deleted table. The autoincr will be reset when you add another
> record and you made room for the 19 new ones. It seems safer to me than
> touching the active issues.
> There is a bug about a script for this, but it got into In Discussion..
>
> Marcel
>
>
> -----Oorspronkelijk bericht-----
> Van: Koha [mailto:koha-bounces at lists.katipo.co.nz] Namens Pedro Amorim
> Verzonden: maandag 23 oktober 2017 14:13
> Aan: Koha list <koha at lists.katipo.co.nz>
> Onderwerp: [Koha] Salvaging data before using DBMS auto increment fix
>
> Hello all,
>
> I want to implement
> https://wiki.koha-community.org/wiki/DBMS_auto_increment_fix on our
> instance, however from my understanding this will only prevent the problem
> from happening in the future, it will not fix the current corrupted data.
>
> I happen to have 19 ids that exist on both issues and old_issues and would
> like to the clean-up before going further. However, I'm not sure how to
> proceed:
>
> 1) Remove the 19 ids from the *issues* table and implement the fix.
> Downside is the data of those 19 issues would be lost and it would be as
> if those check-outs never happened;
>
> 2) Remove the 19 ids from the *old_issues* table and implement the fix.
> Data is lost, would be as if the item was never checked out and then
> checked in again but, in theory, this would open room for the 19 ids in the
> issues when they check-in.
>
> 3) Update the 19 ids in the *issues* table to the next 19 ID's available,
> move the AI value 19 upwards and check if it's +1 than the current
> max(issue_id). This is, in theory, the best way as no data is lost, those
> 19 ID's in *issues* table would have their ID's available in the
> old_issues table, and the fix prevents the problem from happening in the
> future.
> However this sounds the most risky way to go about it.
>
> Would anyone give me advice or their opinion on this? Am I looking at this
> the right way or is there some other better way to work around it?
>
> Thanks a bunch,
>
> Pedro Amorim
> _______________________________________________
> Koha mailing list http://koha-community.org Koha at lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
> _______________________________________________
> Koha mailing list http://koha-community.org Koha at lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
> _______________________________________________
> Koha mailing list http://koha-community.org
> Koha at lists.katipo.co.nz
> https://lists.katipo.co.nz/mailman/listinfo/koha
>
More information about the Koha
mailing list