Error upgrading from 3.1.2.4 to 3.3.0.11

Describe the issue or problem
I get an error when trying to upgrade from 3.1.2.4 to 3.3.0.11

Steps I took leading up to the issue
I am using cpanel from my hosting site

Database server

  • Server: Localhost via UNIX socket
  • Server type: MariaDB
  • Server version: 10.3.36-MariaDB - MariaDB Server
  • Protocol version: 10
  • User: xxxxxxx
  • Server charset: cp1252 West European (latin1)

Web server

  • cpsrvd 11.104.0.10
  • Database client version: libmysql - mysqlnd 7.4.30
  • PHP version: 7.4.30

phpMyAdmin

  • Version information: 4.9.7

What application are you using?
For example, OJS 3.1.2.4

Additional information
Here is the error

A database error has occurred: SQLSTATE[42S01]: Base table or view already exists: 1050 Table ‘temp_authors’ already exists (SQL: CREATE TABLE temp_authors AS SELECT * FROM authors)

A database error has occurred: SQLSTATE[42S21]: Column already exists: 1060 Duplicate column name ‘email_id’ (SQL: ALTER TABLE email_templates_data ADD email_id BIGINT)

Hi @drfurtado

That error is indicative of a previous upgrade attempt that failed. If an upgrade fails, you usually need to restore your database from a backup made prior to the upgrade, because the upgrade process creates temporary tables and these tables cannot exist when you re-run the upgrade otherwise you’ll see errors like the ones you’ve posted.

Best
Jason

1 Like

Hi @drfurtado

Additionally, to Jason’s comments… although upgrade should work directly from 3.1.2-4 to 3.3.0-12, it’s recommended to go first to 3.2-stable (or 3.2.1-4).

Cheers,
m.

Thank you for the reply.
Is there a way to delete the duplicated tables and then upgrade?

I am afraid that restoring the databases will impact/delete all papers that were published since the backup. Would it be the case?

I recall that I attempted to upgrade about 6 months ago, and after receiving the error, I went back to 3.1 from a backup.

Hi @drfurtado

The problem is that it isn’t just tables - there have possibly been other schema modifications made, for example in your original post you shared the error about a column already existing.

To be able to revert these would mean walking back through the schema changes and undoing the SQL queries that ran thus far, a process that would be very error prone and would possibly break your installation.

And yes, rolling back to a previous backup would affect data since the backup was made.

if you originally rolled back to a 3.1 backup and used that database to run this upgrade, it sounds like that backup contained the remnants of another upgrade attempt made before that?

Best
Jason

Thanks again for the response.
Would it be easier to create a new installation with the latest version and migrate the content to the new installation.

Hi @drfurtado

The Native XML plugin can only move between OJS installations that are using the same version. So you could set up another 3.1.2.4 install, import your content into it, and then upgrade. However the export plugin will not migrate the workflow of a submission, just files and published content. You’d lose for example the editorial history.

Best
Jason

1 Like

This is a good idea.
I am wondering if the import would preserve URLs and DOIs since these are used for indexing purposes… we currently use Google Scholar.

Also, are you aware of a migrate tutorial that you could recommend?

Much appreciated.

in my experience;
Since the IDs of the articles will change, their URLs will also change.
DOI URLs need to be updated. (Updating your metadata)

Google Scholar re-indexes (takes time)