A user has come to me with the following problem (error report) while attempting to upgrade OJS. Even though I asked, I was not informed what version it is. By the type of error you might know…
file: /www/ojs/lib/pkp/classes/db/DAO.inc.php
DAO.update(INSERT INTO notes (user_id, date_created, date_modified, title, contents, assoc_type, assoc_id) VALUES (?, '2016-02-..., Array[5])% line 212, file: /www/ojs/lib/pkp/classes/note/NoteDAO.inc.php
NoteDAO.insertObject(Object:Note)% line 1498, file: /www/ojs/classes/install/Upgrade.inc.php
Upgrade.convertQueries(Object:Upgrade, Array[1])% line 0, file:
<h1>DB Error: Data too long for column 'contents' at row 1</h1>ojs2: DB Error: Data too long for column 'contents' at row 1
I haven’t come across anything like this before.
Duplicate entries have been found and removed, I believe.
However, this kind of error makes me shiver and assume that exporting data may be a cleaner way to start fresh, even if some data loss may occur, which must be planned as we did.
Is there anything that can be done or starting fresh, exporting data and moving submissions manually seems the best solution at this point?
I would suggest restoring the database from pre-upgrade attempt backup, then using the command-line tool (tools/upgrade.php) to try again. This should provide information about what stage of the upgrade was in progress when the problem occurred.
It’s possible that they’ve inadvertently changed their database settings, which might cause data to appear to grow if the encoding gets garbled. This might happen if the config.inc.php settings around database encodings and connection encodings got changed accidentally.
In any case, there should be a reasonably easy solution that won’t require anything convoluted, if we can determine where in the upgrade process the failure occurred.
Regards,
Alec Smecher
Public Knowledge Project Team
Check the comments_to_ed column in the articles table of your OJS 2.x journal to make sure it doesn’t have any unexpected/overlong content such as spam. That column should be able to hold quite a bit of content (65,535 characters, give or take depending on your character set configuration and whether your content contains e.g. accents).
Regards,
Alec Smecher
Public Knowledge Project Team
You must have a character encoding problem on your server configuration or database.
You won’t be able to fix this now and it wouldn’t be wise to do so. Restart your upgrade from scratch.
When upgrading, it is wise to first let OJS 3 install the database, as it will create it with the correct encoding. You’ll need to set Apache and the folder to the correct character enconding (UTF-8).
Then, empty the database and dump into it your OJS 2 database.
Then run the upgrade process, preferably from command line.