Upgrade from v3.1.1-2 to v3.1.1-4 fails

Hi,

unfortunately I can’t upgrade to v3.1.1-4 because of this error message:

ERROR: Upgrade failed: DB: Incorrect string value: ‘\xD9\x81\xD8\xB9\xD8\xA7…’ for column ‘subject’ at row 1

Is this an encoding problem?
in the config.inc I defined utf8:

; Client output/input character set
client_charset = utf-8

; Database connection character set
; Must be set to “Off” if not supported by the database server
; If enabled, must be the same character set as “client_charset”
; (although the actual name may differ slightly depending on the server)
connection_charset = utf8

; Database storage character set
; Must be set to “Off” if not supported by the database server
database_charset = utf8

; Enable character normalization to utf-8 (recommended)
; If disabled, strings will be passed through in their native encoding
; Note that client_charset and database collation must be set
; to “utf-8” for this to work, as characters are stored in utf-8
charset_normalization = Off

in the php error log it says:

[Wed Nov 28 15:35:57.229426 2018] [:error] [pid 60222] [client 10.153.124.104:51245] PHP Notice: Only variables should be passed by reference in /opt/ojs-arc/plugins/generic/customBlockManager/CustomBlockManagerPlugin.inc.php on line 65, referer: https://arcadia.ub.uni-muenchen.de/arcadia/issue/archive
[Wed Nov 28 15:35:57.277872 2018] [:error] [pid 60222] [client 10.153.124.104:51245] PHP Warning: Declaration of SubmissionFileDAO::fromRow($row) should be compatible with PKPSubmissionFileDAO::fromRow($row, $fileImplementation) in /opt/ojs-arc/classes/article/SubmissionFileDAO.inc.php on line 23, referer: https://arcadia.ub.uni-muenchen.de/arcadia/issue/archive

Thanks for help,
Anna

Dear all,

sorry to ask again, but does anybody have an idea, what is going wrong with this update? Do I have to change anything in the database?

thanks, Anna

Dear all again,

can anybody support me?

thanks, Anna

This message does seem to suggest an encoding problem in the data.

Have those config.inc.php settings always been with the current values?

Thanks for your reply.

We only set up the journal in august with v3.1.1-2 and since this time I can’t remember that we changed the encoding.

I thought about setting up a new database and use the recent database dump, but I suppose I will only go along with the problem?

If there is actual data corruption in a database table which can be resolved by restarting/restoring the database, then setting up a new database might resolve the problem. This is not likely, but I have seen it before in a different context.

Given the message “for column ‘subject’”, I’m going to suspect this is bad data in the email_log.subject table, as entered by a user when sending a email through the workflow.

If I were approaching this, I would probably do a dump of the database to an SQL backup file (for example using mysqldump in the case of mysql) and look in that file for strings which were malformed. If there is a malformed string, can this record be updated to clean the data?

ok, thank you very much, I will try this approach

Hi Graham,

I found the encoding mistakes in the mysqldump: the data in the table email_templates_default_data
is completly malformed.
This is quite strange because this journal is completly in English and German is disabled at all.
The locales under are correct, the mistake is only in the database.

I will correct the dump and import it again. Hopefully that solves the problem.

Thanks again,
Anna

Hi @ctgraham

I corrected the malformed data in table email_templates_default_data and imported this dump, but still the upgrad doesn’t work. the error message is still the same:

ERROR: Upgrade failed: DB: Incorrect string value: ‘\xD9\x81\xD8\xB9\xD8\xA7…’ for column ‘subject’ at row 1

there is now table email_log.subject in my dump, as you suggested.
Do you have any other suggestions, what might cause and solve the problem? I am quite helpless.

Thanks, Anna

Hi @ctgraham

problem solved: I compared my dump with another ojs-dump and realized that the charset was set wrongly:

CHARSET=latin1;

I changed it in the dump to utf8 and the upgrade script ran successfully. I have no idea, why it was set to latin1, but I am glad the problem is solved.

thanks for your support,
Anna