omo66 wrote on Friday, October 23, 2009:
The top and left navigation display (radio buttons layout)
are displaying the name but not the PID#.
Another problem related to PID:
After sending a fax normally I can go to admin->document and then find the fax listed with drop box- selection to update the fax and move it into the appropriate document folder.
With this release V 3.1.0 there is an error:
Error processing file '6948512_fax_.pdf the specified patient id ‘512’ could not be found.
omo66 wrote on Friday, October 23, 2009:
PS:
I loged out and in then the left navigation display (radio buttons layout) are displaying again.
It apprears that clicking in admin–>documnets-> '6948512fax.pdf caused to reset the PID variable some how???
bradymiller wrote on Monday, October 26, 2009:
hey,
How are you having the admin->documents choice show up? Is this a globals switch?
-brady
omo66 wrote on Monday, October 26, 2009:
No, it is a default setting. All faxed documents are going into admin->documents with drop menu for save-into some folders.
Today I noted this problem again. The PID is not displaying on some patients.
I am using, Ubuntu 8 and SSL connection.
ANY ideas?
bradymiller wrote on Tuesday, October 27, 2009:
hey,
I don’t have experience with faxing; will attempt to set up for testing purposes. Quick questions, are you running multiple isntance of OpenEMR at once in your web browser? Also, is this pid stuff only associated with the faxing/documents (if anything else can reproduce it, let me know, since otherwise need to wait til i figure out how to get faxning stuff going.
-brady
omo66 wrote on Tuesday, October 27, 2009:
It is not related to FAX.
There are patients all (many?) who were created as new (since upgrade) are always failing to show the PID. I could reproduce the error by selecting these patients
omo66 wrote on Tuesday, October 27, 2009:
PS:
This OEMR has all files with version 3.1.0 except
ajax_template.htm this was imported from 2.9.0 ( I could not fix the calendar other than replacing this file)
bradymiller wrote on Wednesday, October 28, 2009:
hey,
Just to ensure not missing any obvious my-sql database corruption issues or bad settings do the following:
1) Check the my-sql database for corruption with the ‘mysqlcheck’ command:
2) Check out the my-sql config file (my.cnf). IF there is a sql-mode variable, paste it here.
-brady
omo66 wrote on Friday, October 30, 2009:
I have not checked above yet.
I looked at patient_data table- of patients with (working PID , non-working-PID).
All new patients created after upgrades are missing the ‘pubpid’ field.
I filled in this number into patient_data–> fixed for now
I need to know why that field is not saving any longer?
bradymiller wrote on Friday, October 30, 2009:
hey,
This is not happening in the demos. It really seems like there are several possible issues here:
1) Database corruption (run mysqlcheck command)
2) MySQL setup (sql-mode parameter in your mysql setup)
3) Unsuccessful upgrade/migration (in the adminstration->database screen in middle top column there is ‘openemr(103)’; do you see 103?)
-brady
omo66 wrote on Saturday, October 31, 2009:
I have not tested the MYSQL commands as you suggested.
I changed: line 433 in globals.php to false
$GLOBALS = false;
It is now saving normally.
I am worry about changing MYSQL settings since I am dealing with production server.
Do you have any idea which line has that sensitive MYSQL query?
omo66 wrote on Saturday, October 31, 2009:
I looked again at dB structure. This OEMR-dB used to be 2.9.0
The Collation has three different types:
utf8_general_ci
utf8_bin
latin1_swedish_ci
The new release table has only one type (utf8generalci)
Could this be the cause for this problem?
Will all users with dB-Versions 2.9.0 and older have similar issues?
bradymiller wrote on Saturday, October 31, 2009:
hey,
This is fine. All users previous to 3.1.0 will have a "hybrid database". Users that want to use UTF-8 characters (like chinese, greece, etc) will need to convert to pure utf-8 (way 3.1.0 now is), but others do not. So, this is not what is causing the problem. There seems to be something very global going wrong with your OpenEMR instance, and attempting to patch it by blocking off code will likely be fruitless. You need to check for table corruption (this is a rather comon problem if the server does an unsafe shutoff ie. power outage) and ensure the sql-mode parameter in your mysql configuration files does not have certain settings.
-brady
omo66 wrote on Saturday, October 31, 2009:
During initial upgrade I got this message below: Is it an ACL error?
ACL ERROR:
Checking to ensure all the proper ACL(access control list) are present:
‘Administrators’ group ‘write’ ACL is present.
ERROR, ‘Physicians’ group ‘write’ ACL does not exist.
‘Clinicians’ group ‘write’ ACL is present.
‘Clinicians’ group ‘addonly’ ACL is present.
ERROR, Multiple ‘Front Office’ group ‘write’ ACLs are present.
‘Accounting’ group ‘write’ ACL is present.
Adding new object sections
The ‘Sensitivities’ object section already exist.
Adding new objects
The ‘Normal’ object in the ‘Sensitivities’ section already exist.
The ‘High’ object in the ‘Sensitivities’ section already exist.
The ‘Pharmacy Dispensary’ object in the ‘Administration’ section already exist.
The ‘ACL Administration’ object in the ‘Administration’ section already exist.
The ‘Price Discounting’ object in the ‘Accounting’ section already exist.
Upgrading objects
The ‘High’ object in the ‘Sensitivities’ section has already been updated.
Updating the ACLs(Access Control Lists)
The ‘Superuser’ object of the ‘Administration’ section is already found in the ‘Administrators’ group ‘write’ ACL.
The ‘High’ object of the ‘Sensitivities’ section is already found in the ‘Administrators’ group ‘write’ ACL.
The ‘Normal’ object of the ‘Sensitivities’ section is already found in the ‘Administrators’ group ‘write’ ACL.
ERROR,unable to place the ‘High’ object of the ‘Sensitivities’ section into the ‘Physicians’ group ‘write’ ACL.
ERROR,unable to place the ‘Normal’ object of the ‘Sensitivities’ section into the ‘Physicians’ group ‘write’ ACL.
The ‘Normal’ object of the ‘Sensitivities’ section is already found in the ‘Clinicians’ group ‘addonly’ ACL.
The ‘Pharmacy Dispensary’ object of the ‘Administration’ section is already found in the ‘Administrators’ group ‘write’ ACL.
ERROR,unable to place the ‘Pharmacy Dispensary’ object of the ‘Administration’ section into the ‘Physicians’ group ‘write’ ACL.
The ‘Pharmacy Dispensary’ object of the ‘Administration’ section is already found in the ‘Clinicians’ group ‘write’ ACL.
The ‘ACL Administration’ object of the ‘Administration’ section is already found in the ‘Administrators’ group ‘write’ ACL.
The ‘Price Discounting’ object of the ‘Accounting’ section is already found in the ‘Administrators’ group ‘write’ ACL.
The ‘Price Discounting’ object of the ‘Accounting’ section is already found in the ‘Accounting’ group ‘write’ ACL.
ERROR,unable to place the ‘Price Discounting’ object of the ‘Accounting’ section into the ‘Physicians’ group ‘write’ ACL.
ALL DONE
bradymiller wrote on Saturday, October 31, 2009:
hey,
Those are errors, unless you meant to remove the ‘Physicians’ in acl->admin. You also seem to have a redundant ‘Front Office’-write group, which is odd. To get back to the ‘default’ groups you’ll need to go into administration->acl to config, and I’d use the demos as a reference. It’s also a bit weird, because this is the acl 3.0.1 upgrade script(NOT the 3.1.0 acl upgrade script), which make me think something criticially wrong with your upgrade to 3.1.0 (ie. are you sure you fully replaced the web server openemr directory with new code) The missing of the physicians group is not a source of your above errors though. Just more evidence that something more systemic is going on (database corruption or mysql settings or something wrong during upgrade).
-brady
omo66 wrote on Saturday, October 31, 2009:
**PROBLEM SOLVED:**
for all users NEVER change pubid as unused in admin-> layout option
If you do then you suffer the same pain I had for past days-nights.
I suggest to block this option.
You could easily reproduce this error on the dem-dev as above.
bradymiller wrote on Saturday, October 31, 2009:
wow,
makes sense, what an awful experience for you. Good for us to know about this. Could you post this in the bug tracker so we don’t forget it, and then we can consider a mechanism to not allow or warn when disabling core stuff from the layouts.
-brady