Mysql_pconnect() problem

biller wrote on Monday, January 10, 2011:

Hello all, I’m having a problem.  I am receiving this error

Warning: mysql_pconnect() : Access denied for user ‘admin’@‘localhost’ (using password: YES) in ~/library/adodb/drivers/adodb-mysql.inc.php on line 335
Check that mysqld is running.

Warning: mysql_error(): supplied argument is not a valid MySQL-Link resource in ~/library/sql.inc on line 20

ERROR: Could not connect to server!

I can access phpmyadmin and see all the data.  I even exported the data and installed it on another computer.  I just can’t seem to figure out what I did to make it unaccessible.

Thanks in advance for your help  John

aperezcrespo wrote on Monday, January 10, 2011:

Hi,
   What OS are you using?  Windows?  Linux and if Linux what distribution?  What  OEMR? 3.2 or 4 dev?

Thanks

biller wrote on Monday, January 10, 2011:

Ubuntu 8.04 OEMR 3.0

If you need anything else please let me know

Thanks again for helping me try to resolve this  John

drbowen wrote on Monday, January 10, 2011:

If you can access the phpMyAdmin then likely the MySQL server/demon is running.  Is there evidence that there is data in the tables and that you can search the tables?

The ‘admin’@‘localhost’  password may not be set.  This error message will occur if you are using a password but the password has not been set.

Please post your operating system and version, versions of PHP, MySQL as Alfonso suggests above when posting this type of question.

Sam Bowen, MD

aperezcrespo wrote on Monday, January 10, 2011:

Any particular reason for not using the current release 3.2?  The deb install package will take care of any dependencies and setup for you.
Instructions:
http://www.openmedsoftware.org/wiki/OpenEMR_3.2_Ubuntu-Debian_Package_Installation
Download:
http://downloads.sourceforge.net/openemr/openemr_3.2.0-1_all.deb

biller wrote on Monday, January 10, 2011:

It may very well be a dependency issue, however, it was working fine on Friday.  I upgraded one of the installations to 4.0 and then I started receiving that error in another database. I have still yet another database with that same version and it is working fine.  It just seems to be that one database that I messed up.   I am trying to upgrade them, however, some people don’t care much for change so we are introducing each practice to the upgrade one at a time to lessing the stress on them and us =)  I was just wondering would would cause that error.  If I’m able to fix it on the original server it would be fantastic.

Thanks again  John

biller wrote on Monday, January 10, 2011:

I am also trying to learn what I did to muck it up so I don’t make the same mistake in the future.  I am hoping that by finding out how to resolve the connection issue it might shed some light on what I did and I can make a mental note not to do that again =)  Thanks again for helping me fix this issue and learn a little more about it as well.  John

drbowen wrote on Monday, January 10, 2011:

Generally, we leave the “admin” password left as “pass.”  This has to do with the GACL in case you have to break into your own database. Can you try connecting manually with the admin username and using the command line?

Sam Bowen, MD
http://oemr.org

biller wrote on Monday, January 10, 2011:

It doesn’t give me a chance to enter the username or password when I type in the link ie.,  www.website.com/oemr it brings up that connection error.  It doesn’t bring up the usual log in page.  We leave the user name for admin as admin and just change the password.  I hope that makes sense.  Thanks John

biller wrote on Monday, January 10, 2011:

drbowen sorry for the long delay I missed what you said earlier about MYSQL and PHP.  Our version of MYSQL is 5.0.51a and our version of PHP is 5.24 .  I was able to look in the database using phpmyadmin and yes there is data there.  I looked at the user table and it lists admin with some encrypted password.  I was upgrading one database when I lost the connection to this one.  I’m thinking has has something to do with session id’s or something like that I just can’t figure out exactly what broke the connection.  Thanks again for assisting me.  John

drbowen wrote on Tuesday, January 11, 2011:

On the affected server, I still think that you need to check that the username and password pair are working from the command based on the above error messages.  In MySQL

admin
‘admin’@127.0.0.1
‘admin’@‘localhost’
‘admin’@‘mysever.com

are all different users. 

When the first page is being loaded, before you ever get to the login prompt, the script is accessing the database to determine what the initial login group(s) is.  So the initial Login page needs database access before you realize it.

Sam Bowen, MD

biller wrote on Tuesday, January 11, 2011:

drbowen, thanks so much for that suggestion.  I think I need a little help on how to check the associating between the user names and passwords, if that is what you were suggesting.  I entered mysql in a terminal, it did bring up the mysql prompt, I just don’t know what comes next =)   Another thought is that all the other practices we have set up on that server are working fine.  I think I did something to break the link in this one instance?  If I reset the user name name and password in mysql, will that affect the other instances of oemr?  Thanks again for helping figure out what I did to mess this one instance up.  John

biller wrote on Wednesday, January 12, 2011:

I believe I figured out what I did to initially cause this problem.  I installed version 4.0 onto a webserver that already had other installations of OEMR.  I think my mistake was not changing the session name ~interface/globals.php line 118.  I looked at my fresh install of 4.0 session name and the install of the database that it messed up and they both had the same session name.  If this did in fact cause my problem how might I go forward and fix it if that is even possible.  Thanks for all your help John

drbowen wrote on Friday, January 14, 2011:

You are running multiple installations on the same server.

How many installations are you running?

One of the instances is writing to the wrong instance of MySQL?

Are you running logging on the MySQL server?

How much data has been misconfigured?

When were your last backups run?

Assuming you are running binary logging, the above can be restored.  Restore to your last backup on the affected instance.  Then edit the binary logs to delete the bad inserts.  Rerun the good inserts on the backup to catch up the data to the current position.   This will lose the least amount of data but depends on your being able to pick the bad inserts.  Most likely everything after a specific date:time will be a bad insert.  Delete these inserts from the wrong instance of the database and reapply them to the correct instance database. 

There is a built in binary log viewer that comes with MySQL that will make this much easier:

http://dev.mysql.com/doc/refman/5.0/en/binary-log.html

http://www.mydigitallife.info/2007/10/06/how-to-read-mysql-binary-log-files-binlog-with-mysqlbinlog/

Sam Bowen, MD

biller wrote on Monday, January 17, 2011:

drbowen, ty very much for that info.  We have 5 installations running.  Yes that is what I believed happened when I installed version 4.0 I didn’t change the session info so the default session info which I believe is openemr conflicted with another database that had that as its session name.   I kinda did what you suggested.  I went back to my last back up made from oemr and restored that to another server just to be safe.  I did some tests on that data and I was able to upgrade to 3.2 without the problems I was having above.  I was afraid to mess around with the inserts as you mentioned as I didn’t want to mess up the other data bases as I have never looked at those files.  At least its running now and I know what I did so I have to be carefull when upgrading future instances of oemr not to make the same mistake again.  Thanks again for everyones help it is greatly appreciated.   John