blankev wrote on Sunday, May 18, 2014:
Is it possible to have two versions of OpenEMR, the latest stable version and Development version run with the same MySql database on a server?
Can I switch between to two versions without harming the older version?
fsgl wrote on Sunday, May 18, 2014:
Hi Pimm,
Are both on the same partition?
When you started, I would think that both databases were identical. With use, one would think that they were be different without synchronization. How have they remained the same?
blankev wrote on Sunday, May 18, 2014:
Both versions are in the same sub-directory. Some more explanation:
I have a starting page:
Version 4.1.2_patch 5: www.pblankevoort.com/xxx/xxx/OpenEMR_Stable/login
(working great for me but I want more, stuff not included in the patch before the official next release)
and
version: www.pblankevoort.com/xxx/xxx/OpenEMRDev_latest/login
In upgrade instructions it is stated that you can copy and move some files and directories and the new version works with the old parameters. At the end you have to run the Patch upgrade and you get a nice screen that tell you that the installation was successful and the openings screen works with the same parameters and the database is so constructed that none of the old information is lost.
So my intention is to run the old stable version. Whenever I am in need of new modules of Developers (Track anything and Document Templates) I login through the New_Dev Site login screen.
Sounds complicated but with the information that newer Versions should be compatible with the older versions, I thought may be there is no harm done, if I login with Dev version and if it works for me implement the newer version. (But it has to be a stable situation and not something with many errors)
Another option might be to include the Development files from Github, with some kind of SQL to upgrade the tables.
yehster wrote on Sunday, May 18, 2014:
One tricky part is with the “document” directory since the two version will try to save them in different places.
In general database changes for the development version are additive, so the older version will most likely safely ignore the additions. However when using the “Stable version” data may be “missing” for the development version. Whether this will result in “harm” really kind of depends on your usage.
If I’m interpreting Pimm’s question correctly he’s talking about having two separate copies of the PHP files that have identical settings for the database in sites/sqlconf.php. There is only one database in that situation. “Both version” modify the same MySQL data.
blankev wrote on Sunday, May 18, 2014:
Yes, you have my question correct.
I am afraid to use the same Database, but on the other hand, it would save me a lot of trouble switching to and from etc. if all works as expected.
fsgl wrote on Sunday, May 18, 2014:
Because you are not using OpenEMR in your medical practice, any mishaps would be inconvenient but not disastrous.
If something nasty does happen, restore a backup (and sin no more).
Linux Mint 17 is out. You were going to re-do things anyway.
blankev wrote on Monday, May 19, 2014:
Documents are saved in different Directories. Can you explain where both versions save their documents an how? Is there an option to Copy => paste the contents of one Directory to the newer Directory spot?
bradymiller wrote on Monday, May 19, 2014:
This just seems like a bad idea 
You could solve the document issue by using soft link of directory of one to point to the other; or you could use the couchdb feature to point to the same couchdb database.
The reason this seems like a bad idea is because the interplay between the codebase and the database are not the same across versions; and risk that strange things will occur.
-brady
OpenEMR
fsgl wrote on Monday, May 19, 2014:
Well, Pimm, now that El Jefe has spoken, do you plan to live recklessly or are you going to do the sensible thing?
blankev wrote on Monday, May 19, 2014:
The sensible thing is not a solution for my problem. Our older EMR product was only XP compatible, for me a nice moment to convince my colleague of the change to OpenEMR. But within the waiting time span for version 4.1.3, I am stuck with making the new forms with “notes” and “referral” or any other included FORM to create my own forms and do some additional programming in the related files.
I want to include the Rod Document templates but I can not find where the instructions are stored to use “a part of the latest development version” in the “Version 4.1.2 patch 5” version.
Please HELP.
blankev wrote on Monday, May 19, 2014:
Brady, tnx for the comment. The latest Development V4.1.3 seems to be stable with the many options I need. Can I do an install and an sql.php upgrade 4.1.2 => 4.1.3 comparable to an upgrade of version 4.1.1 to 4.1.2 as stipulated in the WIKI pages of openEMR and have a fair chance of thing working as in the Demo?
Is there a problem with SSL and or other hidden features I did not have or use in Version 4.1.2 Patch 5 ?
fsgl wrote on Monday, May 19, 2014:
So you are using OpenEMR in a semi-production mode?
I don’t know how to implement Brady’s suggestions and perhaps you don’t either.
Since the upgrade to 4.1.3 is not yet available, it might be simpler to use only 4.1.3 Dev. for the time being. If it proves to be too unstable, the fallback is 4.1.2.
Hopefully when the stable version of 4.1.3 becomes available, your partner will be convinced to transition to OpenEMR, then this exercise will be moot.
blankev wrote on Monday, May 19, 2014:
Tnx for your never ending support. I did some digging into Reports and found some solutions, and with a bit of tweaking I can get a rather nice HTML page. If the prinitng of those pages works, I did accomplish what could have been done with Development templates in a wink.
I am not complaining, just observing and I like to try the latest if available.
bradymiller wrote on Tuesday, May 20, 2014:
Hi,
You should be able to upgrade to 4.1.3-dev version just like you would normally upgrade OpenEMR (this is much more safer/straightforward than trying to run different versions of OpenEMR on the same database). The key thing to remember is that when you upgrade to the the official 4.1.3 in the future you still put 4.1.2 on the sql-upgrade script (this may actually be a moot point since there is a new developer working on an algorithm to automate that script anyways without selecting a version anyways). With development version you do run the risk of bugs, but the codebase at this point shouldn’t be to buggy (it will likely become more buggy as the MU2 deadlines looms closer since a bunch of code at that point will likely be going into the codebase with potential for bugs).
Ensure you do the upgrade on a test site first to ensure it goes well (occasionally there are bugs in the sql upgrade script, which can be painful).
-brady
OpenEMR
blankev wrote on Tuesday, May 20, 2014:
Tnx, I will give it a try. I have a copy of the Dev. Version of last week, and have not read much comments on bugs. I will also screen the upgrade SQL file for parts I don’t need.
Make a back-up Copy and keep my fingers crossed. (Last resort)
fsgl wrote on Tuesday, May 20, 2014:
Excellent. Exploration (trying) is the essence of being young at heart.
Next project, the persuasion of the partner.
bradymiller wrote on Wednesday, May 21, 2014:
Hi,
Recommend not touching the sql upgrade file. A good way to think here is that the codebase is a key and the database is a lock; if you mess with one or the other then it may not work anymore.
-brady
OpenEMR
blankev wrote on Wednesday, May 21, 2014:
I was thinking of taking out ICD9 AND ICD10, since I don’t use these Codes.I also saw some other stuff not related to my general practice. But I will follow your advise and keep everything in place and delete only “my own cerebral memory” of wrong mental conclusions.