Upgrading from v 5.0.1 to the latest

Support
1

I am upgrading from v5.0.1 to 7.03.
I’ve moved the data to a test server to dry run the process.
I am planning to go through the following upgrade path
5.0.1 to 5.0.2 add patch 5
5.0.2 to 6.0.0 add patch 4
6.0.0 to 6.1.0 add patch 1
6.1.0 to 7.0.0 add patch 2
7.0.0 to 7.0.1 add patch 1
7.0.1 to 7.0.2 add patch 3
7.0.2 to 7.0.3 add patch 3

I have reached to 6.1.0 and I can no longer log into the system with the admin password, and I have no option to reset.

Can anyone advise how I can regain access?

Also if there is any advice on speeding up the upgrade process, steps that can be skipped from above, I’d appreciate it.

Thanks.

2

hi @Puff, you should be able to upload directly to 7.0.3without going thru each individual step you’ve outlined.

There may be a gotcha in there somewhere along the way but we should be able to help diagnose by looking at the php error logs.

3

I looked through the upgrades from each version to the next. The only notable change in folder location was from 5.0.1 to 5.0.2 with the edi and era folders moving into the documents folder. Other than that everything looked straight forward. I’ll consider doing it that way when I have to do the client’s actual data.

However at this stage I am still concerned about getting back into the system without any of the usernames and passwords working.

4

You can look in the log table in the openemr database with phpmyadmin to see the login error.

5

Thanks, I am looking at the logs and it show a login event for user ‘admin’. Under comments, there is a long string of numbers and letters.

6

It’s base64 encoded.

7

Thanks, it says user password incorrect

8

Do you think this can be avoided if I improve the username and password complexity before I start the upgrade process?

9

@stephenwaite any thoughts on that option?

I’m planning to restart the process on Monday.

10

hi @Puff , would upgrade to 7.0.3 on the test machine and then debug why the password was incorrect (if interested) or reset them then.

11

@stephenwaite what’s the reset process?

12

Are you asking about resetting the database to upgrade again?

13

No. I would still like to try resetting the password in the current state.

The password from v 5.0.1 was very basic. I am guessing that it doesn’t meet the requirements for v7.0.3 and would need to reset.

14

The check for complexity is done when the password is set not upon login.

To reset the password you can use this query to change an admin’s password to pass and then you’d have to manually change each user’s password.

UPDATE `users_secure` SET `password` = '$2a$05$MKtnxYsfFPlb2mOW7Qzq2Oz61S26s5E80Yd60lKdX4Wy3PBdEufNu' WHERE `username` = 'admin';
1 Like
15

@stephenwaite thank you very much. That worked.
I have regained access and will be proceeding with the full migration and update on monday.

Thanks again for you help.

1 Like
16

@stephenwaite I only just completed the upgrade. However the client is getting an error when trying to upload a document to the patients

SQL Statement failed on preparation: Select pd.pid, Concat_Ws(‘, ‘, lname, fname) as name, pd.patient_groups, tplId.profile, tplId.member_of, tplId.recurring, tplId.event_trigger, tplId.period, tplId.modified_date as profile_date, tpl.* From patient_data pd Join document_template_profiles as ptd On pd.patient_groups LIKE CONCAT(’%’,ptd.member_of, ‘%’) And pd.pid = ? Join (Select * From document_template_profiles) tplId On tplId.profile = ptd.profile And ptd.active = ‘1’ Join (Select id, category, template_name, location, template_content, mime, modified_date From document_templates ) as tpl On tpl.id = tplId.template_id Group By pid, category, template_name Order By lname’

Query Error

ERROR: query failed: Select pd.pid, Concat_Ws(‘, ‘, lname, fname) as name, pd.patient_groups, tplId.profile, tplId.member_of, tplId.recurring, tplId.event_trigger, tplId.period, tplId.modified_date as profile_date, tpl.* From patient_data pd Join document_template_profiles as ptd On pd.patient_groups LIKE CONCAT(’%’,ptd.member_of, ‘%’) And pd.pid = ? Join (Select * From document_template_profiles) tplId On tplId.profile = ptd.profile And ptd.active = ‘1’ Join (Select id, category, template_name, location, template_content, mime, modified_date From document_templates ) as tpl On tpl.id = tplId.template_id Group By pid, category, template_name Order By lname

Error: Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation ‘like’

/home/removed/public_html/openemr/src/Services/DocumentTemplates/DocumentTemplateService.php at 82:sqlStatement
/home/removed/public_html/openemr/src/Services/DocumentTemplates/DocumentTemplateService.php at 883:getPortalAssignedTemplates(1,1)
/home/removed/public_html/openemr/controllers/C_Document.class.php at 111:renderPortalTemplateMenu(1,-patient-,)
/home/removed/public_html/openemr/library/classes/Controller.class.php at 157:upload_action(1,31)
/home/removed/public_html/openemr/controller.php at 6:act(Array)

17

hi @Puff, try running this in your mariadb sandbox command line please:

DB="openemr"; ( echo 'ALTER DATABASE `'"$DB"'` CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;'; mysql -uroot -proot "$DB" -e "SHOW TABLES" --batch --skip-column-names | xargs -I{} echo 'ALTER TABLE `'{}'` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;' ) | mysql -uroot -proot "$DB"
18

Hi,

I was able to resolve the above issue by changing the collation of the columns to match.
I noticed that a lot of the database (as much as half ) is still set to utf8_general_ci but new installations are using only utf8_unicode_ci.

Is that a big concern?

1 Like