It looks like the first_name column in the authors table, which has a maximum length of 40 characters, is getting something longer than it expects.
This is odd because the same limit exists in 2.3.7, which you currently have installed.
There are several possibilities I can think of…
Was the column manually extended in your 2.3.7 database? If so, you’ll need to edit lib/pkp/xml/schema/submissions.xml and extend it there too before running the upgrade.
Has your character set configuration in config.inc.php accidentally changed? If so, this could cause non-ASCII characters to take up more space than they should.
Regards,
Alec Smecher
Public Knowledge Project Team
thanks @asmecher for your response.
I had already checked lib/pkp/xml/schema/submissions.xml between version and i can see the same maximum length of 40 characters on lib/pkp/xml/schema/submissions.xml as you already mentioned
Looking for character set i cannot see issues between old and new database server as follows
Old database server
mysql> USE NewDani;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show variables like “character_set_database”;
±-----------------------±------+
| Variable_name | Value |
±-----------------------±------+
| character_set_database | utf8 |
±-----------------------±------+
1 row in set (0.01 sec)
mysql>
new database server
mysql> USE NewDani2485_10;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
mysql> show variables like “character_set_database”;
±-----------------------±------+
| Variable_name | Value |
±-----------------------±------+
| character_set_database | utf8 |
±-----------------------±------+
1 row in set (0.00 sec)
mysql>
/newdani/ojs-2.4.8-5# egrep -i charset config.inc.php
;mysql_set_charset(“UTF8”, $db);
client_charset = utf-8
; If enabled, must be the same character set as “client_charset”
;connection_charset = Off
connection_charset = utf8
;database_charset = Off
database_charset = utf8
; Note that client_charset and database collation must be set
;charset_normalization = On
newdani/ojs-2.4.8-5#
Hmm, that’s confusing, because all the application of lib/pkp/xml/schema/submissions.xml should be doing is reiterating that 40-character limit that appears to already apply. After the upgrade fails, what do you see for entries longer than 40 characters long in the authors table in the first_name column?
Regards,
Alec Smecher
Public Knowledge Project Team
I think this is your problem – there should be no null entries in the first_name column of authors. You can change null entries to empty strings before running the upgrade:
UPDATE authors SET first_name='' WHERE first_name IS NULL;
[Query corrected to refer to authors instead of `users. -AS]
Regards,
Alec Smecher
Public Knowledge Project Team
Yes, that typo correction is right; I’ve noted it above.
It looks like you have the same problem in last_name, so yes, the same fix would apply. I’m not sure why null values are allowed there in your case – they shouldn’t be in 2.3.7 either.
Regards,
Alec Smecher
Public Knowledge Project Team
Let’s treat that separately, as it’s different than the issues in this post – that’ll help keep the forum organized as a resource for others. I’d suggest reviewing existing postings with that error message (e.g. Upgrade failed 2.4.7-1/2.4.8-1 --> 3.0.0), and if those don’t help, post a new one with details on what you’ve tried so far.
Thanks,
Alec Smecher
Public Knowledge Project Team
