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)
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.
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).
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?
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.
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.
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?