V7.0.2 Upgrade bug?

Support
1

Attempting to upgrade to Version 7.0.2, on a clean new host with PHP 8.2 linked to database server running MariaDB 10.5

OpenEMR Version
I’m using OpenEMR version 7.0.2

Browser:
I’m using: Have tested with Firefox , Brave, & Chrome

Operating System
I’m using: Ubuntu 22.04 LTS

Search
Did you search the forum for similar questions? Yes

Logs
Did you check the logs? Yes
Was there anything pertinent in them? Yes
Please paste them here (surround with three backticks () for readability. [php:error] [pid 8329] [client 192.168.1.96:8125] PHP Fatal error: Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in /srv/www/openemr/src/Services/Utils/SQLUpgradeService.php:1076\nStack trace:\n#0 /srv/www/openemr/src/Services/Utils/SQLUpgradeService.php(1076): count()\n#1 /srv/www/openemr/src/Services/Utils/SQLUpgradeService.php(507): OpenEMR\Services\Utils\SQLUpgradeService->CreateImmunizationManufacturerList()\n#2 /srv/www/openemr/sql_upgrade.php(364): OpenEMR\Services\Utils\SQLUpgradeService->upgradeFromSqlFile()\n#3 {main}\n thrown in /srv/www/openemr/src/Services/Utils/SQLUpgradeService.php on line 1076, referer: https://192.168.1.11/openemr/sql_upgrade.php```

Should I roll back to PHP 8.1 and try again?

2

Or add this fix to code if (count($records ?? []) > 0) L-1076 src/Services/Utils/SQLUpgradeService.php

3

Thank You! I will try this tomorrow & report back…

4

Good news, that fixed the PHP error! Now I’m working through a whole other set of problems because for some reason it’s unable to alter the table engines to InnoDB. Looks like I’ll have to let the Upgrade fail there, fix the table engines separately within SQL, and then run the Upgrade again after. Takes a lot of kludges to make this whole process work.

5

It shouldn’t. Something else is going on.
If upgrade is trying to upgrade to InnoDB then this must be from an old openemr version.

6

It is, this is a site that squatted on V4.2.0 for a very long time and has now finally realized that they can’t put off upgrading any longer. It just keeps throwing these at me:


SQL Statement failed on preparation: ALTER TABLE `issue_encounter` ENGINE=?'

Query Error

ERROR: query failed: ALTER TABLE `issue_encounter` ENGINE=?

Error: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '?' at line 1

If I manually fix the storage engine for that table, then it’ll do the same thing again for the next table in the list, and so on. What doesn’t make any sense, is that the same command issued to the MariaDB server via CLI works just fine. I think it actually is sending the “?” instead of “InnoDB” in the command string for some reason. Going to try hard-coding it next and see if that changes anything.

7

Do the upgrade in stages until past v5.0.0 then you can upgrade to latest. This means you may have to follow upgrades by installing the files for the upgrade. It’s been awhile for me but while tedious it is the safest and surest way forward.
The forum has some posts dealing with this type of upgrade that may require some diligent searching.

8

Oh yeah, I’m painfully aware of multi-stage upgrades, several of those posts are mine! (Ouch)
But actually, that did the trick, fortunately this is a comparatively small system with <10000 patients and relatively minimal database table sizes. So, anybody else who might find themselves in this position when a legacy install has to be dragged kicking and screaming up through multiple versions, you may want to do the following-

on line 1153, of …/src/Services/Utils/SQLUpgradeService.php

change this:

$r = sqlStatement(‘ALTER TABLE ' . $table . ' ENGINE=?’, $engine);

to this:

$r = sqlStatement(‘ALTER TABLE ' . $table . ' ENGINE=InnoDB’);

Voila! Problem solved. All the storage engine alter statements execute and in this case the installation actually made it all the way from V4.2.0 to V7.0.2 in one continuous set of operations.

Thanks again for the help Jerry P !!!

2 Likes
9

looks like you found a bug since sqlStatement() expects an array that holds the binds

$r = sqlStatement(‘ALTER TABLE ' . $table . ' ENGINE=?’, [$engine]);
10

Ouch on that bug. Guessing there was a time in past where adodb allowed a non-array for a single bind to explain why this did not fail in remote past when did all this work to convert to InnoDB.