MySQL database connection configuration problem

[Guest]

This is a strange one.

 

I recently took over someone else's installation.

When the client got me "the password" to MySQL, they simply had the host issue a new password to MySQL. When they changed the password, it broke the previously configured connection to MySQL from OSC and I had to update configure.php. No problem - so far.

My two copies of configure.php are good. Same code as below in both:

//  define('DB_SERVER_USERNAME', 'moonpie_0-admin');
//  define('DB_SERVER_PASSWORD', 'oB2KFW');
// changed by alan 11/17/06
 define('DB_SERVER_USERNAME', 'moonpie_0-all');
 define('DB_SERVER_PASSWORD', '3c2d99b2');

I can admin the database - from phpAdmin and from OSC Admin. Everything looks okay. But when a customer tries to log in to their account or check out from the cart, OSC is unable to connect to the database.

Warning: mysql_connect(): Access denied for user 'moonpie_0-admin'@'eth1.ssl.(host).net' (using password: YES) in /nfs/ssl-htdocs/moonpie/catalog/includes/functions/database.php on line 19
Unable to connect to database server!

But configure.php (both copies) is configured with user name "moonpie_0-all" and user 'moonpie_0-admin' should no longer be in the system.

But it is. Somewhere. Where might that be??

 

Where does OSC get 'DB_SERVER_USERNAME' and 'DB_SERVER_PASSWORD' from, besides the two copies of configure.php???

 

Thanks in advance.

Alan, configured and confused....

[Guest]

Some contributions have database configuration options - one I saw recently was a Wordpress "integration"

 

 

Sonia

[Guest]

Some contributions have database configuration options - one I saw recently was a Wordpress "integration"

Sonia

Sonia -

Thanks, I don't think that's an issue here; I don't actually know the history of the installation and whether any contributions have been added - but i haven't seen any indication of that. Still, it could be the problem and I will look into that.

In the meantime, the report gets weirder..

When I echo DB_SERVER_USERNAME and DB_SERVER_PASSWORD to the screen from database.php, it displays the correct values! Yet, when the code calls the connect function on line 19 of database.php - A SECOND TIME in the connection process, the values returned in the error message are different!

Even when I hard code the values in line 19, one call works, but in a subsequent call (apparently from another linked script -or to a different copy of database.php), the login fails and displays the old username!

(line 19 of database.php)
 function tep_db_connect($server = DB_SERVER, $username = DB_SERVER_USERNAME, $password = DB_SERVER_PASSWORD, $database = DB_DATABASE, $link = 'db_link')

Warning: mysql_connect(): Access denied for user 'moonpie_0-admin'@'eth1.ssl.(host).net' (using password: YES) in /nfs/ssl-htdocs/moonpie/catalog/includes/functions/database.php on line 19
Unable to connect to database server!

At this point, I am baffled....

 

Configured, but still confused, Al :'(

[pyramids]

here is a db script that may help locate the trouble spot.

 

It will read the config file and then connect to the database with those settings and report back

 

If it can't connect, then it is a config issue - no need to look further, just need to fix the config.

 

If it reports SUCCESS, then there is a break in your code somewhere.

 

Here is the code to run, save as database_settings.php and run in browser

<?php
// database_settings.php vers 1.0 by pyramids 09152006
// Will print out your database settings and report mysql errors
// Only reads the database it does not write to it
// Run from the shop root as www.mydomain.com/database_settings.php

if (!file_exists('includes/configure.php')) {echo "<font size=4>Can't find the <b>'includes/configure.php'</b> file.   <b>NOTE: </b>This script 'database_settings.php' needs to run in the shop root like mydomain.com/database_settings.php or mydomain.com/shop/database_settings.php depending on your setup</font>";die();}

require ('includes/configure.php');// login info

echo 'My DB includes/configure.php is set to:<br><br>' .
'DB Name: ' . DB_DATABASE . '<br>' .
'DB Server: ' . DB_SERVER . '<br>' .
'DB UserName: ' . DB_SERVER_USERNAME . '<br><br>';

$conn = mysql_connect(DB_SERVER, DB_SERVER_USERNAME, DB_SERVER_PASSWORD) or die(mysql_error());// connect to the DB
if ($conn){echo 'SUCCESS ->> Connected to DB server ' . DB_SERVER . "<br><br>";}

$select_db = mysql_select_db(DB_DATABASE, $conn) or die(mysql_error());// select the DB
if (mysql_select_db){echo 'SUCCESS ->> Selected the DB named ' . DB_DATABASE . "<br><br>";}

  $sql = "SELECT startdate from counter limit 1";// read database
$result = mysql_query($sql, $conn) or die(mysql_error());
 $more_info = mysql_fetch_array($result);

if ($more_info[0] && $conn){echo "SUCCESS ->> DB server is UP and we are able to read it<br><br>";}

?>

[Guest]

Jeff - Thanks. I'll try this and let you know what it returns. My guess at the moment is that the code is indeed broken somewhere, since I have been able to regain some control of the values by editing the two configure.php scripts as well as hard-coding the login values in database.php. I suspect the code was modified - without comments - by the prior web master...

What I found particularly interesting is that when I entered a known bogus value for the login, I did receive an error as expected, but when I corrected the value, I received the troublesome error - returning the old 'admin' login value. And, when I added an echo (varnames) statement to database.php, it did return the correct configuration values - but then errored out because the script did not want to be doing any screen writes...

Yeah. I think my config is correct, but it does seem as though the last guy made some mods but kept the changes to himself - bad behavior in my book - and which may be why my client asked me to take over... I think I'll check the file dates on the php scripts and see if I can find some hidden mods in the system.

 

Thanks. Alan

[Guest]

Jeff -

 

That script is great!!!

 

http://catspajamas.biz/catalog/database_settings.php

 

returns okay all around. It must be something special in the https:// setup on this server.

[Guest]

:rolleyes: :rolleyes: :rolleyes: :rolleyes:

 

Great news. Case closed. The missing configure.php files were NOT ON MY SERVER!!! They were on a different SSL server, accessed via ssl.hostname.com, NOT ftp.hostname.com..

 

That was the entire problem. The configuration files that needed to be updated were not within my primary file system. They were in a different filesystem on a different server entirely.

 

Thanks for all the help and feedback. The problem is solved, I am wiser for the experience, and I sure hope that next time someone runs into a similar problem that they find this thread and check for a secondary ssl files system...

 

- Alan

:thumbsup: :thumbsup: :thumbsup: :thumbsup: