This is the error:
Warning: require_once(/home/content/11/13951611/html/testsite/Sources/Subs-Auth.php) [function.require-once]: failed to open stream: No such file or directory in /home/content/11/13951611/html/testsite/Sources/Errors.php on line 418
Fatal error: require_once() [function.require]: Failed opening required '/home/content/11/13951611/html/testsite/Sources/Subs-Auth.php' (include_path='.:/usr/local/php5_3/lib/php') in /home/content/11/13951611/html/testsite/Sources/Errors.php on line 418
This is syntax that includes line 418:
global $sourcedir;
// Just load the other file and run it.
require_once($sourcedir . '/Subs-Auth.php');
show_db_error($loadavg);
// Since we use "or db_fatal_error();" this is needed...
return false;
I have no idea what to do-
well - it would appear that someone removed the show_db_error function in your installation.
Your best bet, at this point - is to upgrade to 2.0.10 that will fix your error AND get you up to the version path which will be supported (as opposed to 1.1.x which will be dropped from support in the near future)
This is exactly what I've been trying to do. The site exists in a different location but, I wanted to replicate it so if there were any problems it would not effect the running site.
Should I upload the upgrade for this and run it? I'm not certain the running program downloaded all of the necessary tables and structure to do it. I'm really not good at this and I'm the first to admit it.
I created a sql database and uploaded the backup. I know the front end works because the site was running off of the running sql database before I pointed it to the new one.
Any help with this
take a look at http://wiki.simplemachines.org/smf/Upgrading. if you do a good backup there should not be any issues upgrading in place. it may cause you more headaches trying to duplicate the setup and upgrade a test there.
I uploaded the upgrade 2.0.10 files and folders and began the upgrade. this is what the screen looks like now:
Warning: mysql_fetch_assoc() expects parameter 1 to be resource, boolean given in /home/content/11/13951611/html/testsite/upgrade.php on line 860
Warning: mysql_free_result() expects parameter 1 to be resource, boolean given in /home/content/11/13951611/html/testsite/upgrade.php on line 862
Warning: mysql_num_rows() expects parameter 1 to be resource, boolean given in /home/content/11/13951611/html/testsite/upgrade.php on line 1084
Warning: mysql_free_result() expects parameter 1 to be resource, boolean given in /home/content/11/13951611/html/testsite/upgrade.php on line 1086
Unable to find members table!
I don't understand any of this and we have 7 years worth of information here and I'm convinced I'm too stupid to make this happen with a positive outcome. I'm afraid that if I use the upgrade on the running site, I will do something to trash it and we will have nothing. I get this feeling that when I do backups from the admin panel it is not putting all the data and tables in there. If it was why didn't upload with the rest of the files? I certainly don't have a clue.
I'm positive you know a way that I may be able to keep me from killing the site I have running to get me to the 2.0.10 version.
you should not use the backup in the admin panel, it is known for doing a partial backup, you should use phpmyadmin or your hosts control panel.
You can have a similar problem exporting your db with phpmyadmin. If you have a large db and slow connection, it can timeout without error, and leave you with a partial backup. If your host has a cpanel backup, that's usually most reliable. Whichever method you use, repeat the backup 2-3 times and make sure file sizes are the same.
I'm uploading a complete backup now. I did do a timeout but, the site said if I wanted to continue to finish select the backup again and it remembered the position it would continue from.
Should I use the host software to do a database check up to look for errors or try to run the forum software and use the maintenance utility to do this?
Use phpmyadmin to check/repair db tables. That's all server-side, so not subject to timeouts.