i am trying to upgrade from OJS 2.4.8.5 to 3.2.1.4 & got following error, please help.
[28-Aug-2023 17:53:58 UTC] PHP Fatal error: Uncaught Exception: DB Error: Unknown column ‘assoc_type’ in ‘where clause’ Query: UPDATE email_templates SET assoc_type = 530 WHERE assoc_type = ‘526’ in /home/sscldlco/stagetwoscholar.sscldl.in/lib/pkp/classes/db/DAO.inc.php:703
Stack trace: #0 /home/sscldlco/stagetwoscholar.sscldl.in/lib/pkp/classes/db/DAO.inc.php(231): DAO->handleError(Object(ADODB_mysqli), ‘UPDATE email_te…’) #1 /home/sscldlco/stagetwoscholar.sscldl.in/classes/install/Upgrade.inc.php(742): DAO->update(‘UPDATE email_te…’) #2 /home/sscldlco/stagetwoscholar.sscldl.in/lib/pkp/classes/install/Installer.inc.php(417): Upgrade->syncSeriesAssocType(Object(Upgrade), Array) #3 /home/sscldlco/stagetwoscholar.sscldl.in/lib/pkp/classes/install/Installer.inc.php(263): Installer->executeAction(Array) #4 /home/sscldlco/stagetwoscholar.sscldl.in/lib/pkp/classes/install/Installer.inc.php(186): Installer->executeInstaller() #5 /home/sscldlco/stagetwoscholar.sscldl.in/lib/pkp/classes/cliTool/UpgradeTool.inc.php(88): Installer->execute() #6 /home/sscldlco in /home/sscldlco/stagetwoscholar.sscldl.in/lib/pkp/classes/db/DAO.inc.php on line 703
Note : last week i have upgraded from OJS 2.4.2.0 to 2.4.8.5 successfully! After that, i am trying to do OJS 2.4.8.5 to 3.2.1.4 upgradation i am facing te above error.
It’s likely that this is caused by an upgrade that failed and then was attempted again. Are you sure you restored your OJS database from backup if the upgrade already failed?
(It’s best not to double-post the same issue in several places; it might take a while for someone to get to your post, and if you’d like to add a reminder, feel free to add a follow-up post after a week.)
Regards,
Alec Smecher
Public Knowledge Project Team
After you’ve restored your database from backup (the 2.4.8-5 version), what does the schema for your email_templates table look like? It should be something like this…
MariaDB [ojs-stable-2_4_8]> describe email_templates;
+------------+-------------+------+-----+---------+----------------+
| Field | Type | Null | Key | Default | Extra |
+------------+-------------+------+-----+---------+----------------+
| email_id | bigint(20) | NO | PRI | NULL | auto_increment |
| email_key | varchar(64) | NO | MUL | NULL | |
| assoc_type | bigint(20) | YES | MUL | 0 | |
| assoc_id | bigint(20) | YES | | 0 | |
| enabled | tinyint(4) | NO | | 1 | |
+------------+-------------+------+-----+---------+----------------+
5 rows in set (0.009 sec)
Regards,
Alec Smecher
Public Knowledge Project Team
PHP Deprecated: Function get_magic_quotes_runtime() is deprecated in /home/sscldlco/stagetwoscholar.sscldl.in/lib/pkp/lib/vendor/adodb/adodb-php/adodb-xmlschema.inc.php on line 1307
That schema looks fine. Can you attempt the upgrade, and post the full output from the upgrade script here?
Those warnings won’t cause the upgrade to fail, I don’t think, and will probably go away once you’ve completed an upgrade to a recent release of OJS (e.g. 3.3.0-x).
Regards,
Alec Smecher
Public Knowledge Project Team
Every time the upgrade fails, for next upgrade to keep only the previous backup DB restoration is enough, or do we need to copy the ‘files’ folder all over again??
Before running the upgrade command do we need to Set the Type as “InnoDB” to all the tables and set Collation as “utf8mb3_general_ci” to all the tables in DB?
this should be done at every intermediate upgradation level.?
Do we need to Set the Type as “InnoDB” to all the tables?
OJS up to 3.3.0-x doesn’t care whether you use InnoDB or MyISAM, but I do recommend using InnoDB. It’s been the default MySQL storage engine since 2009 and is required for OJS/OMP/OPS starting with 3.4.0.
Do we need to Set the Collation as “utf8mb3_general_ci” to all the tables in the DB?
Your collation/encoding is your own choice; utf8mb3_general_ci should be a good choice. But this is more of a database administration question than an OJS question. Just make sure that your data is actually correctly encoded in that encoding – if you start mixing different kinds of encodings together in your database, it can be very hard to fix!
this [changing the storage engine and collation] should be done at every intermediate upgradation level.?
No, it shouldn’t be necessary to change this regularly. Once you’ve got your storage engine set to InnoDB and your collations sorted out with one of the UTF8 options, they should stay that way.
Every time the upgrade fails, for next upgrade to keep only the previous backup DB restoration is enough, or do we need to copy the ‘files’ folder all over again??
Not all upgrades affect the files directory, but some do. For example, upgrading from OJS 2.x to 3.x definitely rewrites the files directory, and so does the upgrade from 3.2 to 3.3. It’s a good practice to restore the files directory between attempts to upgrade.
Regards,
Alec Smecher
Public Knowledge Project Team
Debes estar pendiente del versión al migra, en nuestro caso pasamos por esta versiones
|3.3.0.14|3|3|0|14|
|3.1.2.4|3|1|2|4|
|2.4.8.2|2|4|8|2|
|2.4.4.1|2|4|4|1|
si falla debe restablecer nuevamente y revisar la base de datos… en especial revisar el motor de la base de datos
