I added 2 records to openemr 7 patch 2.
One directly from openemr with ID 1
Second record was added from portal with register toggled on with ID 2
I activated the delete from globals and was able to delete the first record, but when attempting to delete the second it gave me this error:
I tried to add another patient from portal/ register, I was able to delete it , also created another patient record from New/Search and I was able to delete, why this particular record is stuck, what might of went wrong?
From the web tool I was able to lock on the possibility of the error:
So going to the deleter.php path:
/var/www/html/openemr/interface/patient_file/deleter.php
I found the php is pointing to documents and not to pnotes like in the error screen?
Am I missing something here?
What is the path to form_HIS?
I looked every possible way could not find where is “form_HIS”?
I did delete the forms from contrib to comply with the security recommendations, I do not think it is relevant but nonetheless the creation of the record was before the deletion, I tried to re-institute that folder to contrib but it did not make any difference.
From Apache2 error log this is what I have:
[Tue Mar 21 21:20:29.402319 2023] [php:notice] [pid 63584] [client {IP ADDRESS}:57700] ERROR: OpenEMR SQL Escaping ERROR of the following string: form_HIS, referer: https://{Server}/openemr/interface/patient_file/deleter.php?patient=2&csrf_token_form=97ad516bb849e31ddf58146c2dc862dc862e021b555c9 double free or corruption (!prev)
I am desperate trying to find what is wrong:
Tables in openemr has pnotes table:
Which has ID and PID in it:
Trying to find what is in ID, there are 2 records 1, and 2 while in my database I have only one patient that is stuck and I cannot delete:
Tried to delete 1 since the id of the bugged record is 2, but nothing have changed, I still cannot delete the record:
That was a good lesson to me and a good chance to test the fullbackup3.sh script by Brady that was modified to version 4 and it saved the day.
Never mess up with tables, never ever unless you know what are you doing, I think the above action orphaned pnotes table and dislocated it somehow from the rest where I started to get all kind of server errors, I did remove the old directory, from the backup directory that was daily burned on my DVD-R I was able to restore it, and mysql dump file restored data and everything is back where it should be, I learned a lesson to deal with this beast with respect otherwise it will bite hard.
Things are good, lesson learned.
Update:
Everything is working after restore but when adding from portal with register I am getting the same error that started this thread , referral for form_HIS?
I will not mess up anything I will wait for guidance, it could be a bug.
The flow as this:
I activated the portal with ReCAPTCHA so the register button is good
from the link to {my server}/openemr/portal I registered as a new patient and I was sent an email with credentials to log in
I did log in and I changed the password and signed the 4 documents and logged out successfully
Then from openemr I got the message of a new patient and I verified it is actually added as new
Tried to delete the patient ….Got the error
Will wait for guidance hopefully it is an easy fix.
Any idea why am I getting this error and cannot delete a record? any help is greatly appreciated.
65 views…any single help please? I do not want to delete from tables in mysql, any reason why this is happening?
Any Suggestion to what the culprit is and how to fix it?
hi @Mohammad , it’s a bug, thanks for reporting. Will work on a fix.
try adding a phantom elseif block to trap the odd form name above the final else in the deleter script
} elseif ($formdir == 'form_HIS') {
// when history form is entered in portal
} else {
...This is an encounter form generated from portal history form.
@stephenwaite did you get this resolved?
Huh, prob have to refresh the page so it pulls the updated script in.
actually looks like the script was updated because you avoided the white screen, not sure what’s up, will re-test
on testing confirmed the bug is still there, looks like it’s using a formdir of HIS instead of form_HIS now
Thank you very much , wish you the best.
