Pathing in MySQL Database

[Viper114]

As I mentioned in a previous thread regarding PHP help, I currently have a project in getting our business' website moved to a different host.  The new host has managed to get all of our files and created a test site for me to work with, but it's not working out very well because there seems to be a communication problem between the database and the website itself, according to the new host.  In their exact words they said "The issue is that the pathing in the database is all set to the full domain path (www.blah.com).  I believe there may be a plugin or two that needs to be installed, but I do not know which."  And frankly, I do not know, either.  I've been trying to find something through Google for MySQL Database domain paths, but to no avail, all I can find is how to find the path if you have the database on a Unix machine.

 

What I'm basically thinking is that the MySQL Database of ours that we're using as the test copy needs to have the full domain path changed from www.blah.com (the format our original website's domain path) to blah.newhost.com (the format of the new host's test site).  If I can manage this, I can probably get the test site to communicate properly and begin actual testing to ensure things work.  Would anyone know what to do in this case?

[Pikachu2000]

That is typically specified in an included file (or directly in the script, but that's less common) that calls either the [urlhttp://php.net/manual/en/function.mysql-connect.php]mysql_connect()[/url] function or the mysqli_connect() function, depending which extension you use. I.E. mysql_connect( 'DB_server_hostname', 'username', 'password'). In any event, the hosting company should be able to provide (at a bare minimum) the hostname you'd need to use to connect.

[Viper114]

The original host we're currently using uses our database on a MegaSQLServer that a PHP file contains the connection variables for, and then every other PHP file in the website either uses "require" or "require_once".  Simple stuff, even a bonehead like me can handle that.

 

I've tried to see if the new host can do that, as well, as they told us before we signed up that they have their own such servers.  They haven't got back to me about that yet, they seem determined to try and do it this way, a (seemingly) complex way to try and get things to work (complex to me, anyway).  However, I recently found out that they have PHPMyAdmin available, so maybe there's a method to follow their suggestion with it?

[Pikachu2000]

It should be no different. It should simply be a matter of editing your connection script to reflect the details of the new host.

[Viper114]

Yeah, maybe I should try and get them to set the database up in a similar fashion and provide the information so I can modify the database connection PHP file and do it that way.  It saves me a lot of effort and aggravation trying to figure out what they're currently suggesting.

[Viper114]

OK, so the new host was able to provide the necessary information.  I used that information to update all of the PHP files in our website that contain our database connection variables, and uploaded them to the test site.

 

Did a fat load of nothing, from what I can tell.  It's still acting the same way as before I changed anything.  One step forward, one step back, it seems...

 

The new host is still suggesting about the domain path in the database, so now I'm pretty much falling back on my original question about the database domain path and what plugins they might be referring to.  Any ideas?

[Pikachu2000]

Put this in a script, replace the variable's values with your own, save it as db_test.php, upload it and call it in your browser. See what errors are returned.

 

<?php
$host = 'the hostname you were given';
$user = 'the username you chose/were given';
$pass = 'the password you chose/were given';
$db = 'your database name';
if( mysql_connect($host, $user, $pass) ) {
echo 'Connected successfully. ';
if( mysql_select_db($db) ) {
	echo "Database $db successfully selected.";
} else {
	echo mysql_error();
}
} else {
echo  mysql_error();
}
?>

[Viper114]

OK, so I copied that code, put in the variables I needed, uploaded it to the test site, called it in my browser and this is what it said:

 

Connected successfully. Database db_name successfully selected. (I changed the database name manually to preserve security).

 

So, that's weird.  It's saying the database is working.  Yet the test site is still having issues as if it's not communicating with the database properly.

[Viper114]

Wait, I may have just thought of something important just now that may be relevant to the issue at hand.

 

Way before I started this project, our original host held our database on a MegaSQLServer.  Then, at some point after the previous IT guy I took over from left but before this project started, the original host moved our database without warning to a new MegaSQLServer (I've narrowed it down to sometime early July as the time they did it).  Yet, even though the database moved, the website continued on as normal, as if nothing happened.  It wasn't until like early August that they said "Yeah, we moved your database to a different server." to which I simply though "Wait, what?"

 

SINCE that move of our database to a different server, actually downloading the database from the server using the crontab I helped make with the previous IT proved to be next to impossible.  It would only download like 500kb of data that actually containing nothing important.  It seems when it was moved, the permissions were reset, and trying to use the MySQL Admin tool to look into was impossible, I was denied access to almost everything.  And when I tried to download the database with the crontab, it originally gave an error saying "Got error: 1044: Access denied for user: 'username' to database 'database' when using LOCK TABLES".  I looked around online regarding this error, found a work around that said that using the --skip-lock-tables function in the crontab would bypass this.  Sure enough, it did, and I had a full copy of our database.

 

Now I'm wondering if by not using the Lock Tables function, as it was unnecessary before our database moved, it somehow may have screwed up our database which is why our test site on the new host is acting wonky.  If so, the only way I could see if I can get a nice, clean copy would be for our original host to give me absolute access like I originally had before the move, so I can download it without the --skip-lock-tables function.

 

Is it possible this might be the problem I'm experiencing?