We had upgraded to patch 9 but it was causing too many problems after two weeks we reverted back but now data that are in the tables are not showing where it is suppose to show. Like in the billing table. All the data is there but on the Past Encounter list for the patient. The two week period that we were on the patch 9 code is not populating. It shows encounters that were entered before the update and after the update but not during the updated period.
Any idea what to do to get the data that was entered during the two weeks to show in the encounter list?
Be sure to back up your data. What kind of problems were you having with patch 9? I will guess that the patch modified the database in some way, so your encounter data is not being queried or returned the same as before the patch. Maybe the “problems” can be solved and you can reapply the patch.
I have a back up of the data from both before and and after the update.
I have verified that the data is the same. I still have both version running on their own data bases. We can run them side by side and see the data in one and not the other. If it changed the data then is there any thing I can do change the data back to the format that will allow it to show in the older version?
There were a lot of random issues with us going to P9. Like the calendar would not go forward or back. It would only show the current month, the lbf stopped working, and on an on it went.
Is there any way to change the data back to a format that matches the old?
I thought data was just data. It would all be written the same.
I used two methods to backup the database. One I just copy the whole database from the database folder. The other is to do and SQL dump from the database one with just data and the other with data and structure. This way I have the database in every form that is possible for quick restore. I had to go back before and this is the first time I have had this kind of problem.
thank for the tip. I think I know where the disconnect is now.
Hi,
What patch did you start from? (the last several patches have not modified the database)
Also, have you customized your code at all?
-brady OpenEMR Project
This is to further clarify. When we went forward to the patch 9 I made a complete copy of that days database and code and set it aside. The copies were of the entire database fold not an SQL dump. So, when I applied the patch and updated the database it was not the only copy. When things started going really south two week later. We decided to pull the plug and go back. Now the task was coping the data backwards to the 4.1.5 database. This is where the problem started. I did an SQL dumb of the 4.1.9 data base and emported the data into the 4.1.5 database.
I hope this helps paint a clearer picture of how I got here.
I think there was a customization to the code to include a hospital onset date. But we have just copied that along the away with every update and every patch. We have carried that customization since version 3.0.
I need to merge the data that is in the form_encounter table.
The addition of the office note is the other major modification that we have made but the sections where I am having problems don’t deal with that section of the code to my knowledge.
Copying database folders is far less reliable than a mysql dump. When you export with mysqldump it checks the data integrity as does the process of importing back in.
You might have better luck working with your dump files than with the copied files/folder.
Also, if you don’t shut down MySQL server when you copy the files you run the risk of getting an inconsistent file.
How do you really know that your data/encounters is backed up though? Are you just making that assumption based on the time of your backups or can you actually see the data in the database and it just doesn’t show up in OpenEMR?
If you used your office visit form/LBF entries just merging in the forms_encounters data may not be sufficient.
Yes I can see data in the tables. I understand what you are saying in the way the data integrety can be maintained. The term missing is being applied to the fact that in one database entries are not showing up.
There is no real way for me to know that the data is consistant. I don’t sit and count each of the rows of data to see if they are all in sequence. I do a visual from with in the program. I did do a count of the rows of data and look in the table running a query on the table and the data is in the table but is not showing up in the display within the program. I counted day for day and encounter for encounter and the data was all there from the other database but will not show in the database I copied it to via the mysql import function.
I have found folder backups to be a saving grace on a couple of occations when an update has done a real number on the system… I will remember to shoutdown mysql before copying folders but I do always run analyize on the tables and flush them before using them once I have copied them back to the database.
I reverted everything back to the 4.1 (9) and found the bad data entry in the calendar and now I am left with three original problems after the applying the patch and that is the LBF not loading and the billing not doing the auto post. I can;t think of the other right at the moment.
There is no real way for me to know that the data is consistant. I don’t sit and count each of the rows of data to see if they are all in sequence[
If this were my data, what I would do is setup a new instance of just MySQL Server. Then you could load MySQL dump files of both the pre-upgrade tables and the two-weeks later tables (or generate dumps from the copied folders). A couple of cleverly constructed queries could then determine exactly what rows exist in the “newest tables” that don’t exist in the pre-upgrade tables.
This would at least let you determine with more certainty if the data is actually present, but not showing up in OpenEMR or if it is really gone/missing.