Minor upgrade problems

dhantke wrote on Tuesday, September 27, 2016:

I’m in the process of upgrading from 4.2.0(4) to 4.2.2. The basic process itself seems relatively problem-free, however I have several generally minor customizations and additions to the program that don’t always work so smoothly. Thankfully, they’ve always been discovered by my staff within an hour or less, which gives me time to go back to the previously backed up 4.2.0(4) version without loosing more than an hour’s work. They’ve been good about keeping notes regarding what they’ve done so it’s not too difficult to recreate the small amount that gets lost when reverting to a slightly older backup. I’ve now worked out most of the kinks and feel that I can reasonably reliably upgrade without major problems. I do have one major source of paranoia, however. What happens if I discover a problem down the road? Say, maybe, in a week or two, or maybe even in a month. My questions follows…

Is it possible to “downgrade” the web folder to the previous 4.2.0(4) version, which I know works, (keeping in mind that I would have to copy over the newer era, edi, letter_templates and documents folders much like the reverse of the upgrade process) while still working off the now-upgraded 4.2.2 MySQL database? This would allow me to preserve the newer data within the database and not have to recreate it all over again in the older version. I’ve done a couple of test runs that seem to work out well but I’m concerned that perhaps I might be missing something involving the links between new and old tables, or perhaps a newly essential column in a previously existing table that then won’t have been populated correctly when I then re-upgrade the web folder after having eventually solved my non-patient-data-related problem.

Any thoughts?

visolveemr wrote on Wednesday, September 28, 2016:

Hello David,

Greetings from ViSolve!!!.

It will be a complex task to downgrade the openemr version from our view as this requires revert the code changes.
Hence the most feasible solution would be, downloading the required version of openemr and then copying the all contents and folders inside sites folder of upgraded openemr to the downgrade openemr.

Let us know if this helps.

Thanks
OpenEMR Customization/Support Team,
ViSolve Inc

mdsupport wrote on Thursday, September 29, 2016:

When you make changes to standard code, you need a dedicated test environment. All upgrades involve database changes needed by new code. Murphy loves mismatch between code and database!

Applying changes directly to production and hoping to roll back code after a month is bad for your business.