OJS update [3.3.0-3 --> 3.3.0-4] failing

Hello everyone,

I’m working on performing the update on two instances of OJS to the newest version. The first version will work with no issues, as it’s a fresh install with no data associated with it - it will serve as a rebuild to the second instance.

The second instance, for those that might remember seeing my name, is the one that had a failed update attempted to it when moving to 3.3.0-3. I ran through all the steps necessary to backup all the data (SQL data, documenting the installation files and creating a .TAR.GZ file of those installations, creating manually virtual backups of the server HDD) in order to restore where I was before performing the updates. Though I had these steps automated in the past, I no longer trust the rules to work, hence the situation I’m in.

When I attempt to perform the update on the failed database update from a previous installation, it returns the same error message I received before - 42S22. I’m restoring that database to how it was before but since that SQL database contains all of the tables with the prior data, I was hoping to somehow update it to restore it to the primary instance. I don’t know if that’s possible, hence this post.

@asmecher You were very helpful in working out what I might need to do moving forward previously - what steps would I need to take in order to perform this update?

Thank you.

[SOLVED]

The most inelegant solution, utilizing almost zero SQL understanding, was able to help me fix my problems. I created the new journal instance, fresh OJS 3.3.0-3, with an untouched database. From the old database, which had failed the upgrade, I compared the values, tables, and necessary data across both setups, updated the column values, deleted and added information based on the import of the tables and the errors spit out by phpMyAdmin, and was able to bring (almost all of) the site back up and functioning.

I never want to go through this again so I will echo statements and everything by @asmecher and others - keep backups on backups on hand. I created a new backup policy for the primary volumes stored on our servers for a rotation of stored backups just in case something like this happens again and I’m unable to work on it for as long as I was able this time.

I’m now going to apply user permissions to my primary admin account so that I can access all of the features of the journals that were restored, as well as update all the customization information that I had worked on.

Thank you.

1 Like