iirc the update path should be from 3.9.x to 3.10.x and only then to 4.x

from 3.9.x to 4 shouln't be allowed

I think that was just a typo and he meant 3.10.11.

In one of my sites, a error 500 show up when the update reached to 90.2%. Checking the joomla_update.php log file, stop in this follow line:

joomla-cms/administrator/components/com_admin/sql/updates/mysql/4.0.0-2020-05-29.sql

Line 25 in 132659f

UPDATE #__history AS h INNER JOIN #__content_types AS c ON h.ucm_type_id = c.type_id SET h.item_id = CONCAT(c.type_alias, '.', h.item_id) /** CAN FAIL **/;

Fixing this line to:

UPDATE `editora_history` AS `h` INNER JOIN `editora_content_types` AS `c` ON h.ucm_type_id = c.type_id SET h.item_id = CONCAT(c.type_alias, '.', h.item_id) /** CAN FAIL **/;

I was able to fix this problem.

That doesn’t make sense to me because the only difference I can see between the logged query and your modifications is the table name prefix not being replaced in the log, which is normal for that log, and the names quoting of the table aliases, which should also not make any difference.

Are you really sure that an SQL error was the reason for the 500, i.e. has there been some sql error shown somewhere, or is this just your assumption and the 500 might also have other reasons?

But then, running the next line, another error show up: Error de SQL (1067): Invalid default value for 'save_date'

For fix this, i needed change the order of the sentences, from this:

ALTER TABLE `#__history` DROP COLUMN `ucm_type_id` /** CAN FAIL **/;
ALTER TABLE `#__history` MODIFY `save_date` datetime NOT NULL;

to this:

ALTER TABLE `#__history` MODIFY `save_date` datetime NOT NULL;
ALTER TABLE `#__history` DROP COLUMN `ucm_type_id` /** CAN FAIL **/;

That happens only in PhpMyAdmin when strict mode is on. When the updated runs that query, that does not happen because it switches of some parts of strict mode during the update. So that is also not really the issue.

iirc the update path should be from 3.9.x to 3.10.x and only then to 4.x

from 3.9.x to 4 shouln't be allowed

Sorry, I meant 3.10

In one of my sites, a error 500 show up when the update reached to 90.2%. Checking the joomla_update.php log file, stop in this follow line:

joomla-cms/administrator/components/com_admin/sql/updates/mysql/4.0.0-2020-05-29.sql

Line 25 in 132659f

UPDATE #__history AS h INNER JOIN #__content_types AS c ON h.ucm_type_id = c.type_id SET h.item_id = CONCAT(c.type_alias, '.', h.item_id) /** CAN FAIL **/;

Fixing this line to:

UPDATE `editora_history` AS `h` INNER JOIN `editora_content_types` AS `c` ON h.ucm_type_id = c.type_id SET h.item_id = CONCAT(c.type_alias, '.', h.item_id) /** CAN FAIL **/;

I was able to fix this problem.

That doesn’t make sense to me because the only difference I can see between the logged query and your modifications is the table name prefix not being replaced in the log, which is normal for that log, and the names quoting of the table aliases, which should also not make any difference.

Are you really sure that an SQL error was the reason for the 500, i.e. has there been some sql error shown somewhere, or is this just your assumption and the 500 might also have other reasons?

But then, running the next line, another error show up: Error de SQL (1067): Invalid default value for 'save_date'
For fix this, i needed change the order of the sentences, from this:

ALTER TABLE `#__history` DROP COLUMN `ucm_type_id` /** CAN FAIL **/;
ALTER TABLE `#__history` MODIFY `save_date` datetime NOT NULL;

to this:

ALTER TABLE `#__history` MODIFY `save_date` datetime NOT NULL;
ALTER TABLE `#__history` DROP COLUMN `ucm_type_id` /** CAN FAIL **/;

That happens only in PhpMyAdmin when strict mode is on. When the updated runs that query, that does not happen because it switches of some parts of strict mode during the update. So that is also not really the issue.

Okay. I will check, just wanted report how happen this, and what made the update work

Well if there was a syntax error in our update SQL, all people would have that problem when updating from 3.10, and that's definitely not the case.

Well if there was a syntax error in our update SQL, all people would have that problem when updating from 3.10, and that's definitely not the case.

That is true.