Upgrading 2.4.8 to 3.1.1-2, Illegal mix o collations

Hi,
I’m upgrading via web.
New server, new db (MariaDB)
This was my roadmap:

  • Export 2.4.8 db and imported into a newly created empty db at the new server
  • Copied 2.4.8 /public and /files directories in the new server
  • Copied all 3.1.1-2 files and directories to new server
  • Modified 3.1.1.-2 config.inc.php file to have same values for common variables b2in those had in 2.4.8 and 3.1.1-2’s
  • Set Installed to “Off” in the config.inc.php
  • Initiated upgrade procedure via web, by accessing the public url and following link “if you are upgrading an existing 2.x installation click here”

Then I got the following message:

Illegal mix of collations (latin1_swedish_ci,IMPLICIT), (utf8_general_ci,COERCIBLE), (utf8_general_ci,COERCIBLE) for operation 'replace'

How could I sove this?

Thanks in advance for your help.
Regards,
Juan

Hi,
is not an easy thing to fix.
Your SQL dump from 2.4.8 has default collaction latin1_swedish_ci, your new db has utf8_general_ci as default collaction.
In my opinion your better option is to to fix your SQL dump with command line util like ‘iconv’ and fix table definiton:
DEFAULT CHARSET=latin1 into DEFAULT CHARSET=utf8
DEFAULT COLLACTION=latin1_swedish_ci into DEFAULT COLLACTION=utf8_general_ci

Then reimport from scratch.
If you can use a MySQL 5.7 / 5.8 instead of MariaDB, it it more easy to fix similar problems.
Bye
Zeno Tajoli

Hi @ztajoli,
Thanks for your reply.

I had set in OJS 3.1.1.-2 my config.inc.php file the following configuration, prior to initiating the upggrading procedure, which is the configuration I have in my config.inc.php at the OJS 2.4.8 installation.

;;;;;;;;;;;;;;;;;;;;;;;;;
; Localization Settings ;
;;;;;;;;;;;;;;;;;;;;;;;;;

[i18n]

; Default locale
locale = es_ES

; 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,8 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 = On

You think this could be part of the problem or be the problem itself?
Should I’ve had set connection_charset and database_charset to “Off”?

Thanks in advance for your reply.
Regards,
Juan

I think it ok. But I think you need to work more on DB level, directly on MySQL DB seutp and import
Bye
Zeno Tajoli

Hi,
Thanks for your reply.
I modified the config.inc.php file so it has connection_charset, database_charset and charset_normalization all set to OFF.
So far, I have done nothing to change my sql dump. I was trying with the option of setting these variables to Off.
When upgrading via web, what I get now is the following error:

DB Error: Table 'ojsull_migrate.articles' doesn't exist

Do I still need to convert my 2.4.8 database dump’s collation and default charset?

Thank in advance for your reply.

Regards,
Juan

Hi again @ztajoli
Any help about this?
Thanks in advance
Regards,
Juan

Hi Jascanio, sorry for delay.
My config.inc.php setup is:
locale = en_US
client_charset = utf-8
connection_charset = utf8
database_charset = utf8
charset_normalization = Off

I suggest you to use in your 3.x setup this config, with locale = es_ES if your Linux locale is ‘es_ES’. You can check your setup with ‘printenv’.

Then:
1)Create a new empty db.
2)Open your sql dump file and fix every ‘latin1’ and ‘latin1_swedish_ci’ with utf-8 equivalent.
3)Fix the chars in your sql dump file with ‘iconv’. Now all is ‘utf-8’.
4)Import your sql dump file into the empty DB.
5)Do the migration OJS 2.x → OJS 3.x

Point 2) and 3) are quite difficult, if you can find a local help is better.

Bye
Zeno Tajoli

Hi @ztajoli
Thanks for your reply.
I’ve fixed my db and proceeded with web-based upgrading to 3.1.1-2

I now get the following error:
PHP Fatal error: Call to a member function getFileId() on null in /var/www/html/pruebas/lib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 1029

Any advice will be deeply appreciated

Thanks in advance for your help.
Kind regards,
Juan

Hi Juan,
I think this is a different topic.
The function that gives you the problem is:

     /**
 * Make sure that a file's implementation corresponds to the way it is
 * saved in the database.
 * @param $submissionFile SubmissionFile
 * @return SubmissionFile
 */
private function _castToDatabase($submissionFile) {
	return $this->getRevision(
		$submissionFile->getFileId(),
		$submissionFile->getRevision()
	);
}

I guess that there are same inconsistency DB data about files and submissions.
But I don’t go more further.
Bye
Zeno Tajoli

Hi all,

Regarding:

Call to a member function getFileId() on null in /ojs_temp/rc-3.1.1/lib/pkp/classes/submission/PKPSubmissionFileDAO.inc.php on line 1029

According to Change galley PDF published OJS 3.1.x - #8 by marc, reviewing the file permissions and re-running the upgrade corrected the issue.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher and @ztajoli,
Thanks for your advices
Before I go any deeper, I’ve found out from the journal’s chief editor that there are not few submission files missing, as they lost them during a migration a couple of years ago.
Then, would it be this fact which is interrupting the upgrade procedure or is it a permissions issue?
What do you think it may be?
Thanks in advance for your help.
Regards,
Juan

Hi @jascanio,

It’s possible that the missing files are causing this. You could always try putting dummy documents in place until you’re able to locate the correct files.

Regards,
Alec Smecher
Public Knowledge Project Team

Hi @asmecher,
Thanks for your reply.
I’ll try what you suggest.
Regards,
Juan Ascanio

Hi @asmecher,
Can you think of a way to identify what files are missing?
Thanks,
Juan

Hi @jascanio,

They should be listed as warnings during a test upgrade. Back up your system, try an upgrade, save the warning list, then restore your installation (including files directory, database, and code) from backup. Then get a list of missing files from the warning list. Use that to put dummy files in place, and try the upgrade process again.

Regards,
Alec Smecher
Public Knowledge Project Team