Trying to upgrade to by functioning 2.8.1 system to 2.8.2 and having some problems.
Running on gentoo with
mysql 4.0.24
php 4.4.0
I used my last back up from my functional db for 2.8.1, then applied the upgrade sql, which didn’t actually work, so had to apply the sql commands manually due to the line
ALTER TABLE form_vitals
MODIFY oxygen_saturation float(5,2) default 0;
as no field ‘oxygen_saturation’ was present, so it could not be modified. Once added, it went fine.
set up sqlconf.php to point to my new db, and go to the log in page for 2.8.2.
I keep getting variations of the following error:
ERROR: query failed: select id, password, authorized, see_auth from users where username = ‘admin’ (No Database Selected)
Now, this works _intermittantly_, and refreshing the screen when I get to a patient page causes the different frames to load or fail without an apparent patter.
Well, funny thing that… my 2.8.1 system is an upgrade from 2.6 ea from Pennfirm, and none of the sql upgrade files in the 2.8.1 directory, or the 2.8.2 directories contain any reference to adding the ‘oxygen_saturation’ field until the 2_8_1_to_2_8_2_upgrade.sql files, so that was missed somewhere… but there is no problem with the db with the 2.8.1 setup, it works great. Well, it works… and 2.8.2 is broken.
I will try setting up a new 2.8.1 directory and running the db from it and see what happens, if I don’t get the errors, then I will again think it is the 2.8.2 code.
I can run the queries on mysql and get the appropriate results, of course this doesn’t necessarily mean anything. Any other suggestions on how to test the db?
Ok, I did what I said I was going to, with unsatisfactory results… so then I went into the sqlconf.php file, and set the user to root, and password as appropriate, and it works… everything works.
this is clearly a permissions problem on the mysql side.
"my 2.8.1 system is an upgrade from 2.6 ea from Pennfirm"
There are several potential issues involved.
To upgrade from 2.6ea to 2.8.1 is a big jump with a a lot of releases in between. (I think the answer is yes, but) did you carefully apply all the patches without skipping to get to 2.8.1?
MySQL 4.0.24 is getting dated. What you are descibing could be a MySQL privilege problem. If I remember correctly, I think the latest version of the MySQL 4 series is around 4.1.23. There is a big jump from 4.0.24 to 4.1. It is necessary to upgrade MySQL serially. To do this correctly you have to upgrade 4.0.24 to 4.1.0 first. Then run mysql-fix-privilege-tables. Then upgrade to 4.1.23 (or the latest 4.1 series). Run mysql-fix-privilege-tables after every MySQL upgrade.
All of this this should be done before trying to upgrade to MySQL 5 (if you choose to do so). If you want to upgrade to MySQL 5 you have to first upgrade 4.1.23 to 5.0.0. Then 5.1. then 5.* current.
Yes, I did the upgrade serially. I have been terrified to upgrade mysql, or php for fear of breaking openemr. In order to do this, I think I will need to parrellel this to a new server, perform the upgrades, do the testing, then if all works well, consider putting it back onto my emr server.
I can’t run as root on the mysql access… so that has to go away. sigh. it’s never easy. There is some stuff in the 2.8.2 that may be worth the effort. and maybe not.
one approach to update is using a new mysql database,
like 0702_openemr,
then copy the whole openemr directory to openemr.old,
change the database name in configuration file,
and start upgrading,
if any thing goes wrong while upgrading,
you can allways mv openemr.old openemr and restore the old setup in a second,
or just create a new directory openemr.new (and enter that info in the config files)
apply all upgrades, and when it’s working mv openemr.new openemr (and enter that info in the config files)
you can have several copies of openemr in a single server,
If you have already successfully upgraded OpenEMR, upgrading the MySQL was (scary) but not as hard.
I was running a Dell small business server with a P4 3G and 128 meg of RAM. We clearly had outgrown the server so I installed Gentoo on a AMD 64 turion (dual chip) with 1 G of RAM, SATA hardrives etc.
The problem I ran into was the Gentoo default MySQL at the time was 4.1.23 but the version on the small Dell server was 4.0.11. Simply dumping the database from the small Dell and loading the tables onto the new server didn’t work because the MySQL tables were too dissimilar.
I finally had to resort to upgrading the older server MySQL on the live data. I shut the automated replication I had going so that I had an emergency copy. I then performed the upgrade on the Dell to 4.1.0. ran the fix privileges, then 4.1.0 -> 4.1.23. I then dumped the database and loaded it onto the new MySQL server. This is the recommended procedure by the mysql.com.
At that time I had a 19 gigabyte database (compressed) and transfers across the network took 20 minutes. I also have a very large InnoDB table since I load all my scans into the MySQL database.
I am currently running PHP 5 and MySQL 4.1.23 on the production server. I haven’t tried to upgrade to MySQL 5.
Upgrading the PHP generally doesn’t seem to cause problems.
Also, If you have a large database, you may need to modify /etc/mysql/my.cnf . I remember having to make a couple of changes though I think these mostly had to do with my single large InnoDB table.