No IDs changed.
Row 1 - Label Name changed to Title and then back to Name
Row 2 - Blank changed to Full Name and then back to blank
Row 4 - lname UOR changed to unused and then back to optional
Row 8 - Label in ss changed to I.D.No. and then back to S.S.
Hope this will help. By the way the Demo dev still cannot backup using the builtin backup utility with Ubuntu 14.04LTS.
Look in both error logs (/var/log/apache2/error.log & /var/log/mysql.err) immediately after you get the pop-up error message & post the fatal errors from 4.1.2 (7).
We’ll deal with the backup problem in 4.1.3 after we get 4.1.2 straightened out.
Because the layout_options table is in disarray, it may be simpler to do a reinstall of 4.1.2 (7). I hope you have a backup that pre-dates the recent round of customization.
My production OpenEMR-4.1.2p7 server is on a Fedora 20 machine. It is fine with the builtin backup facility and I am able to edit the Demographics in the layouts. The problem is editing/correcting error data entered by the frontdesk. I can run 4.1.3-dev just like 4.1.2p7 in all aspects in F20.
I noted with Ubuntu 14.04 and LinuxMint 17 (as in other posts) there is a problem with the builtin backup facility and problem with editing some data in the demographics/insurance section. With 4.1.3-dev I have the added error message with saving the demographics layouts with or without changes made.
If the U14 & LM17 are test copies, we should work on them first. If editing is not possible in F20, it’s corrupted, too.
Are you able to dig up an old backup when the editing problem did not exist? If yes, I would suggest reinstall of U14/LM17 & restore with the old backup.
If the U14/LM 17 machines are 32 bit & this is the error:
Using the test Linux Mint 17 with OpenEMR-4.1.2 patch 7 on localhost , after the fix and changing …vars=3000, the built-in backup facility worked and there is no error message on editing layouts for demographics. (I still get this with 4.1.3-dev). Editing of demographics is still not possible. I do not have earlier backups to test but a fresh OpenEMR installl though possible is not an option for the main production server as it would be a gigantic task!
After upgrading and patching a new version sometimes there is a need to do more. In the past it was mentioned that re-doing the Patching/Upgrading steps again could solve problems (fsgl did suggest this in my memory).
Don’t know if these steps would solve your problems, or make it worse.
Definition: If it works in a Demo, you should be able to get it working in you own local or Web version.
Trace your version of OpenEMR in Github and find the differences. For differences in the Database you can look for problems in phpMyAdmin and compare the Demo and your own working version. Always make backups of both entities of OpenEMR, OpenEMR-software version and OpenEMR-Database before changing! (This last suggestion,not the Backup but the changes, is not for the fainthearted nor for in-experienced USERS)
Thank you all for the help and advice. I will have to double check what the front desk staff do before the first demographics data are saved. Only rarely do my practice have patients changing companies/insurance but if they do they will need to pay out of pocket when they leave the present work place.
I have old clones (TIB) of my disks but I do not think they hold much openemr data since the server was used as the production only the last three months after many months of data entry!
If you take the failing query and attempt to execute it directly against mysql from the command line or using mysql workbench more details about the problem will be revealed.