Hi Jason I did it as you instructed to note all the information output to the terminal. I was able to fix the main errors (two actually) and at the second run, all went rather smoothly and I could display the login window. Still some issues to be fixed through library maintenance with some perl scripts, which I believe might be the source of the OPAC still not returning search results on the catalog. For example I had messages like this one: Upgrade to 19.06.00.018 done (Bug 11529: Add medium, subtitle and part information to biblio table) NOTE: misc/batchRebuildBiblioTables.pl should be run to populate the fields introduced in bug 11529. It may take some time for larger databases.
I understand that either I should be able to log in as staff administrator to perform that task OR get into a koha shell to run that script. Is that correct? I am now trying to find how to reset the superlibrarian password to be able to log in to perform that maintenance. Quynh ================= M. Vũ Đỗ Quỳnh (Ph.D) Trường Đại học Thăng Long - Université de Thang Long - Thang Long University (Hanoi, Vietnam) Phó Hiệu Trưởng, phụ trách HTQT - Vice-recteur chargé de la coopération internationale - Vice-Rector in charge of International Cooperation Web: http://thanglong.edu.vn/ Vào Th 6, 15 thg 5, 2020 vào lúc 23:57 Jason Boyer < [email protected]> đã viết: > Replies inline below > > On May 15, 2020, at 12:48 PM, Quỳnh Vũ Đỗ <[email protected]> > wrote: > > Hi, > > > Vào Th 6, 15 thg 5, 2020 vào lúc 22:25 Jason Boyer < > [email protected]> đã 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: [email protected] <[email protected]> > web: https://EquinoxInitiative.org/ > > _______________________________________________ Koha mailing list http://koha-community.org [email protected] Unsubscribe: https://lists.katipo.co.nz/mailman/listinfo/koha
