@mdsupport that is what I was thinking but there are so many things I don’t know about this database. But the good news is that I was able to convert the database up to v5.0.1 (4). Brought up the program and the data was there and working. So, my next step is to convert this up to 6.0.0.
Yes, I got a more powerful machine. Not what @brady is running but better.
Intel® Core™ i5-4460S CPU @ 2.9 GHz 16GB RAM 120GB SSD
@juggernautsei, You can always bypass guid problem by commenting out the guid insertion during upgrade. If my understanding is correct, the background service could then run for days while your production system is up and running. @sjpadgett can confirm but I would guess only function impacted by partial absence of uuid data will be FHIR. Must have been some compelling reason that eludes me why that is not the standard approach for upgrade.
My issue is not the background service. My issue is that the upgrade is not completing to get into the program. It is forced to finish all the UUIDs before I can log in. The error below is what I get when the screen freezes and ends the log show. If I go to the log-in screen which does come up and log in. Below is what I see.
Because the log quits doesn’t mean the upgrade stops. Status is a completely separate process and run in browser with fetch requests to get server status. So even if you send a sql request to server, it will run to completion regardless of server status state.
UUID is currently only used by FHIR however, Brady wants to eventually use UUID throughout openemr thus, he’s getting headstart with v6 upgrades.
You could perhaps reorg your sql upgrade script to get all the requires table changes in prior to the uuid updates.
The update may be able to be sped up if perhaps we generate a pool of UUID’s we can pick off before upgrade run.
My thinking is the slow down is due to generating the UUID dynamically per sql request. At least I think that’s how it works. I’ll take a look!
Oh, you can turn Server Status on and off with the green button on panel. I knew folks would want to blame it for long upgrade runs so I added that feature. So, don’t be ablamin me folks.
Second Oh yeah: The UUID is dynamically created by API’s if it doesn’t exist so not putting in UUIDs should be okay.
@juggernautsei You don’t make this easy. So here is my final comment on this topic.
What I suggested was change this line to :
$number = ’ NO (bypassed)’; // $uuidRegistry->createMissingUuids();
If uuid is your real problem, now upgrade will bypass that step completely. As @sjpadgett notes, your 6.0 database will be fully functional - just first response to FHIR calls will be s-l-o-w…
Best.
1 Like
I want to thank everyone for their input and comments. For those that are reading this tread. Here is the conclusion.
This has been a hardware issue from the beginning. I took the same code that I started with and put it on a machine with the specs above. The original database with no changes and to the original code with the modification that was posted by @stephenwaite.
It ran right through in under an hour. I logged in. The database has been upgraded.
My advice is to make sure you have adequate hardware resources to do this upgrade from 4.2.2 if you have a database that is 1.6GB in size.
2 Likes