Larry’s situation does not parallel your own. Without a more recent post from him, my best guess is that he did .sql and acl upgrades for 4.1.1 instead of just a .sql upgrade for 4.1.2.
Great that 4.1.1(14) is still functioning and that your office is not reduced to pen and paper.
Hope that you don’t have to upgrade MySql as well because with greater changes comes greater chance for error. Being completely ignorant of Linux, this is not even an educated guess on my part.
We need to be patient for a knowledgeable Linux user to lend a helping hand.
Best to sit tight and do nothing for now. If there is a long hiatus, I’ll nudge the process along.
I copied the sites/default/sqlconf.php from my working 4.1.1 to that in 4.1.2 as root but I still cannot get the new version installed either upgrade or fresh install… The furthest I got on upgrade from 4.1.1 (with patch 14) was not being able to login despite using Admin or previous users with the correct password.
I noticed that the 1.8.0 XAMPP package contained MySql 5.5.25a, while the newest XAMPP-OpenEMR package has MySql 5.5.32. Is it possible that if you have MySql 5.5.25a installed that there is an incompatibility? Do you think you need to do other upgrades as well?
I do not use XAMPP package. I think the problem arose because Fedora 19 do not use the non-opensource MYSQL but"Server version: 5.5.31-MariaDB MariaDB Server". I think Ubuntu has also done the same with the newest version. May be openemr has to follow suit to make it competable with the new opensource MYSQL!
I did not mean to imply that your operating system is Windows. What I meant was because MySql was upgraded in the XAMPP package for Windows users, that perhaps you may need a more current fork of MySql to upgrade OpenEMR to 4.1.2 or to do a clean install of 4.1.2 for your Linux machine.
I remember that the more up-to-date XAMPP was not compatible with 4.1.0 and an older version was bundled with it for the XAMPP-OpenEMR package.
Explore the idea of upgrading MariaDB (to 5.5.32?) for now. Do you know (I don’t) if you also need to upgrade Apache and Php as well?
I have requested help and hopefully it is on the way.
If I am not mistaken I just upgraded Fedora 18 to Fedora 19 using FEDUP and there was no need to migrate physically to MariaDB. It was done seamlessly on the usual Fedora update using YUM. MariaDB wiki mentioned something of incompatibility with the native Oracle Mysql created databases.
Additional information pertaining to this problem.
OpenEMR 4.1.2 running on Slackware current kernel-3.9.10 32bit
Appache-2.4.4 with SSL enabled, PHP-5.4.17, MariaDB-5.5.31
Random DB disconnects where restart of mysqld solves the problem for a few minutes.
Updated MariaDB to 5.5.32 and rebooted the server. The problem seems to have gone away.
At first, update alone was not enough to prevent the problem from recurring. It was only after server restart that it made some progress.
I have updated to mariadb-5.5.32-8.fc19.i686 using the fedora-update-testing repos and also updated the php.ini as in the wiki. I still cannot fresh install openemr-4.1.2. At the firefox browser navigation entry, openemr/setup just do not continue to progress. I have no problem reinstalling Openemr-4.1.1 as long as I drop the openemr database from mariadb using the usual cmdline.
OpenEMR has not been tested with MariaDB; guessing MariaDB is not a “drop in replacement” for mysql yet, as they claim:
I think Kevin may of been tinkering in with this. Pretty sure Ubuntu has not started using this though. Sounds like Fedora may of been a bit premature to go with this, though, since this sounds like it essentially will break some mysql based software (such as OpenEMR 4.1.2). Thing to do is to look through the MariaDB and php error logs to see if can pinpoint the issue. Guessing at some point, as MariaDB matures and gets into other releases developers will start using it and get things working, but were obviously not there yet.
I noticed that if I transfer/copy the setup_sql from v4.1.1 to v4.1.2 database, setup seemed to get the fresh installation of openemr-4.1.2 started but it hanged after making the database “openemr” … strange if mariadb is the problem.
Hanging does not get the job done. Either it is or is not successful (like being somewhat pregnant). Please think outside of the box.
If the upgrading to MariaDB to 5.5.32 does not work, how about downgrading to the prior version of MarieDB, or whatever form of MySql, that was compatible with OpenEMR 4.1.1(14) and re-try the upgrade to 4.1.2(1)?
XAMPP 1.7.4 or higher was not compatible with OpenEMR 4.1.0 and XAMPP 1.7.3 had to be used. I am using this as an example, not that Fedora uses XAMPP.
I can do a fresh install of openemr-4.1.1 with mariadb-5.5.32-8 (the present installed version).On upgrade from 4.1.1 to 4.1.2 , I can upgrade the databases as in the instructions. I can see the openemr login screen. On login with admin/pass or other adminstrator password I cannot start up openemr. The browser just remain blank. When I made a fresh install with 4.1.2 after deleting the previous version from both mariadb and the /var/www/html sites I am not even able to start setup. If I transfer the sq_setup.php form 4.1.1 setup progressed till the part on installing users and then stopped progressing.
Can you provide more explicit details of the steps you are attempting?
Trying to pull different versions of the setup_sql.php script from various packages does not seem like a viable plan. I’m guessing that your problem is that your database is in some weird state, and it’s not a problem specific to MariaDB.
My suggestion is to take a more systematic approach. A mysqldump file from MySQL should be compatible with MariaDB.
Step 1. mysqldump openemr to a file from “old 4.1.1” server
Step 2. copy mysqldump file to new server with base packages (apache,php mariadb) installed
Step 3. import dump file
Step 4. Put clean copy of 4.1.2 OpenEMR files in the webserver directory
Step 5. Edit sites/default/sqlconf.php (change the $config=0 to 1), update the login/password, etc. variable as appropriate
Step 6. Run the sql_upgrade.php for 4.1.1-4.1.2
Your server ought to work at this point.
However, something you can test out is verify the existence of the new “users_secure” table in mysql.