Replies inline below > On May 15, 2020, at 12:48 PM, Quỳnh Vũ Đỗ <quyn...@thanglong.edu.vn> wrote: > > Hi, > > > Vào Th 6, 15 thg 5, 2020 vào lúc 22:25 Jason Boyer > <jbo...@equinoxinitiative.org <mailto:jbo...@equinoxinitiative.org>> đã viết: > Hi, this sounds similar to a problem I ran into recently upgrading a 3.20 > database to 19.11. You’ll probably have to do the drop/re-import procedure at > least 2 more times to fix this, but doing this should help: > > By this I understand I should try to do incremental drop/re-import, i.e. once > one drop-reimport cycle is successful, I would mysqldump the "upgraded" 19.11 > database containing the 3.18 values and then drop again the database to > reload it with the new dump of the 19.11. Is this interpretation of mine > correct?
Not quite. Because an error early on can cause additional failures later, the process I’m referring to is this: 1. Load the 3.18 database 2. Try to upgrade it to 19.11, and save all of the output 3. Drop the 19.11 database 4. Load the 3.18 database again 5. Fix the issues from the 19.11 upgrade output 6. Try to upgrade to 19.11 again, saving the output again just in case 7. If there are additional errors at this point, make note of them, then go to step 4 and try again, fixing the old issues and these new ones. When you are able to load the 3.18 database, make a few specific data / constraint changes, run the schema upgrade with no errors, then you’re done and your database will be in good shape. (This is a great time for a fresh backup :-) ) > > Instead of using the web interface, after re-importing the 3.18 database use > koha-upgrade-schema <instancename> at a terminal and capture the output in > whatever way is convenient to refer to later. At some point there will most > likely be some kind of error that will cause an update to fail, though the > upgrade script will continue on. In my case it was an invalid default value > for the created_on timestamp (0000-00-00 0000:00) on the virtualshelves > table, but it could be any number of things depending on past/present mysql > versions and data consistency. > > Collect all of the errors in the koha-upgrade-schema output and find out how > to address them, then re-import the 3.18 db once more and fix them before > running koha-upgrade-schema. If you need help solving the problems I believe > the output of koha-upgrade-schema is safe to post publicly if you’d like to > attach a text file or share a link to a paste with the list (but you may want > to double-check before doing so). > > > Do you think that it would be safe enough to fix values leading to fault by > doing phpmyadmin edition directly in tables ? like replacing value > "0000-00-00" by "NULL" for instance? > > Quynh If you’re more comfortable with phpmyadmin that should be fine. The most important thing is to make all of the required changes before starting the schema upgrade. Jason -- Jason Boyer Senior System Administrator Equinox Open Library Initiative phone: +1 (877) Open-ILS (673-6457) email: jbo...@equinoxinitiative.org web: https://EquinoxInitiative.org/ _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
