[Koha] Staff login problems after upgrading from Koha 3.18 to 19.11

[Quỳnh Vũ Đỗ]

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 <
jboyer at equinoxinitiative.org> đã viết:

> Replies inline below
>
> On May 15, 2020, at 12:48 PM, Quỳnh Vũ Đỗ <quynhvd at thanglong.edu.vn>
> wrote:
>
> Hi,
>
>
> Vào Th 6, 15 thg 5, 2020 vào lúc 22:25 Jason Boyer <
> jboyer at 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:  JBoyer at EquinoxInitiative.org <JBoyer at EquinoxInitiative.org>
> web:  https://EquinoxInitiative.org/
>
>