Switching web hosting providers, smf problems in transferring.

Started by NewOverlord, April 04, 2019, 01:09:35 PM

Previous topic - Next topic
Print
Go Down Pages1
User actions

NewOverlord

April 04, 2019, 01:09:35 PM
I'll try and summarise.
I've had my story writing forum for just over four years. It's been through two hosting's with it's own cPanel login details, but to save money I've added it as an add-on domain with a different company. (It's going to save me £100 a year in theory.)
I did a full back up before the transfer, thankfully, and I transferred the files over as soon as I was able too.

When I switched the nameservers-after being locked out of doing so-, my forum died-along with the other pages attached to it.

It now says;

Connection Problems
Sorry, SMF was unable to connect to the database. This may be caused by the server being busy. Please try again later.

Now, I've been talking to my hosting guys, and they've ran me through a few things.
I created a blank database with a user, and after some failed attempts at importing the .sql file to the blank database, it's finally live (2.74gb though... :o ) but the site isn't.
(I say some failed.. apparently the exported database on the old hosting provider's 'phpMyAdmin' didn't include all the files. I had to download the full backup that I created, and grab the sql file from that instead. The .sql file I had to import went from 413mb, to 2.74gb.)

I've already added the 'repair settings' file, and I've changed the database name and user to the new one that I set up-and also changed the paths and URL's section to match the new location in my file manager, but I'm still getting the problem.
My site is still down.

Any help on this is greatly appreciated. I'm really feeling bad about the whole thing right now :'(, and I'm not sure what I should do next to fix the problem.  :-[

Doug Heffernan

#1
April 04, 2019, 05:01:59 PM
If the database details are entered correctly in the Settings.php file then the problem lies with the server.

For a file that size it is best to use another script to import it rather than phpmyadmin as it is known for having time out issues with large files.

P.s. Can you check the database and make sure that it has been imported properly btw?

Sir Osis of Liver

#2
April 04, 2019, 05:07:33 PM
Quote from: NewOverlord on April 04, 2019, 01:09:35 PM
apparently the exported database on the old hosting provider's 'phpMyAdmin' didn't include all the files. I had to download the full backup that I created, and grab the sql file from that instead. The .sql file I had to import went from 413mb, to 2.74gb.)[/i]

A database dump doesn't contain files, they're tables.  A 413 mb .sql should not balloon to 2.74gb unless it's zipped.  In any case, I agree with doug, it's unlikely pma imported the entire db, that's why tables are missing.  If you don't know how to use a third party utility to import the db, your host support should do it for you.
Even if the whole world has forgotten,
The song remembers when.
                              - H. Prestwood

GigaWatt

#3
April 04, 2019, 05:21:33 PM
You could also try BigDump. Make sure you set PHP version to 5.6 or something lower (the tool hasn't been updated since 2015 I believe).
"This is really a generic concept about human thinking - when faced with large tasks we're naturally inclined to try to break them down into a bunch of smaller tasks that together make up the whole."

"A 500 error loosely translates to the webserver saying, "WTF?"..."

NewOverlord

#4
April 05, 2019, 06:23:49 AM
Quote from: doug_ips on April 04, 2019, 05:01:59 PM
For a file that size it is best to use another script to import it rather than phpmyadmin as it is known for having time out issues with large files.
I have a ticket open with the current provider, one person-James- has been really helpful and actually offered to import the files when I was having issues with it. I uploaded it to the root directory in my file manager, and he imported the full .sql file for me on his end. (Along with a couple of the failed ones.) He was the one that said that certain files were missing, and has told me what to do, what to look for and where to go throughout the whole thing. He's been amazing, I was panicking a little as I think he left work around 5pm yesterday, and hadn't had a reply from anyone else until almost mid-night last night.

Quote from: doug_ips on April 04, 2019, 05:01:59 PM
P.s. Can you check the database and make sure that it has been imported properly btw?
I didn't need to check that it had, as I said, James actually told me that files were missing. 
ERROR 1064 (42000) at line 1530944: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near

'<!DOCTYPE HTML><html lang='en' dir='ltr'><head><meta charset="utf-8" /><meta nam' at line 1



Quote from: Sir Osis of Liver on April 04, 2019, 05:07:33 PM
A database dump doesn't contain files, they're tables.  A 413 mb .sql should not balloon to 2.74gb unless it's zipped.  In any case, I agree with doug, it's unlikely pma imported the entire db, that's why tables are missing.  If you don't know how to use a third party utility to import the db, your host support should do it for you.

Ah, see that would explain it...  ???
I was actually okay using the phpadmin area, it was just a problem with the file in the end. I need to import the other databases for the other parts of the site, but I won't bother with the phpadmin from the old host, just in case. I'll use the files from the backup as I know that actually worked.
All else fails, I can always see if James can help out again.


Quote from: GigaWatt on April 04, 2019, 05:21:33 PM
You could also try hxxp:www.ozerov.de/bigdump/ [nonactive]. Make sure you set PHP version to 5.6 or something lower (the tool hasn't been updated since 2015 I believe).

Thanks for the suggestion! :) I'll definitely give this a try if nothing else fails.



From the sounds of it though, it was just a hosting issue. The ticket reply I had back around midnight my time, was from a different person-Tommy- simply asking me to try the site again. And, I'm guessing that what I did was fine, because it worked-albeit with a few issues that I resolved in five minutes with the repair settings file.
All the hard work that James and I put in, and I'm pretty sure Tommy just flicked a switch for it to work in the end. Not quite sure what wouldn't work, but it seems to be holding up so far.
So my main forum is back, thankfully -phew!-  8) I just need to get the other pages working now. Hopefully that won't be as much of a pain as I know roughly where I should be looking.
Print
Go Up Pages1
User actions
Advertisement: