News:

Bored?  Looking to kill some time?  Want to chat with other SMF users?  Join us in IRC chat or Discord

Main Menu

We need HELP badly...

Started by Novice, September 05, 2015, 04:31:00 AM

Previous topic - Next topic

Antechinus

OK, hang on a minute. Try not to talk about "files" when talking about database stuff. It just confuses the issue. Database tables just contain a/ structure and b/ data. I mean sure, you have to import from an SQL file, but that's kinda different.

In the context of an SMF forum "files" or "working files" are the critters that lurk inside the forum root directory (Sources folder, etc).

The upgrade files have nothing to do with importing. They're a completely separate process that you run after the importing is done and dusted. You don't worry about them until after you get a notice telling you the database import has succeeded.

Anyway, without being there it's a bit tricky to figure out exactly what's going on. If you have attempted to import once and the process failed, you would need to drop the database tables again before having a second go at it. Otherwise the second attempt will conflict with the stuff that was imported on the first attempt (giving errors about duplicate this and that).

IF the import process is timing out, there should be an option in the import panel that looks like this:

"Partial Import:
Allow the interruption of an import in case the script detects it is close to the PHP timeout limit."

Make sure that one is ticked.

There may be a limit on how large a file you can import from. This is near the top of the import page:

"File to Import:
File may be compressed (gzip, bzip2, zip) or uncompressed.
A compressed file's name must end in .[format].[compression]. Example: .sql.zip
Browse your computer:(Max: 8,192KiB)"

That example is just from my test server. IF your host has imposed a limit of 10 meg (just for an example) and your SQL backup file is 12 meg, the server will refuse it. The only way around that is to manually split the file down into smaller files, and then import those in sequence.

Antechinus

Question: how large is the backup file? And roughly how large was the forum at the time, in terms of posts, members etc?

That may give an indication of whether your backup is complete or partial. IF it's only partial, it may be useless anyway.

Antechinus

Quote from: Novice on September 05, 2015, 10:18:58 PMAbout that duplicate key error: is that on the first run through the import process? Or did it stop, and then you tried again?
First Run

Just saw this edit. Ok, that's a nuisance. The log_whatever tables (errors, search, topics, etc) can give trouble sometimes. The content from log_search isn't strictly necessary. You can always rebuild the search index in admin if you can get the rest of the process sorted.

The catch is that removing the offending content from the SQL backup requires manual editing. It's simple in principle, but depending on the size of the backup it can be a PITA.

Kindred

no no no no no....


first of all, you seem to be confusing DATABASE with FILES.

The database has tables and rows. It does not have files (well, not as far as you are concerned)
The forum itself runs from php files.

You should never install the version from your host control panel. Who knows what configuration they set there or how to import/fix things.
Use the standard install archive from our download link.

then, once 2.0.10 is installed THAT WAY - THEN drop all tables from the database and attempt to import the backup

once that is done, THEN run upgrade.php
Слaва
Украинi

Please do not PM, IM or Email me with support questions.  You will get better and faster responses in the support boards.  Thank you.

"Loki is not evil, although he is certainly not a force for good. Loki is... complicated."

Antechinus

I doubt if GoDaddy would have done anything to the installation pack that would cause a duplicate key error on an empty database. That sounds more like a fairly common glitch with content of log_**** tables to me. It does turn up every so often.

If GoDaddy have frigged around with 2.0.x I can see it possibly causing problems once the site is running, but I can't see how it would cause problems with a empty database (which by virtue of being empty, could not be frigged around with by the host, if you see what I mean).

I think at this stage it'd be best to find out how many meg the backup is. From that we could tell if it's complete or not. If it's a borked backup from the old SMF admin, no point carrying on with this. It's only worth proceeding if there's a good chance the backup is complete.

Sir Osis of Liver

Was the original forum on GoDaddy?  They have a cpanel backup that saves a .sql file to a backup directory in your account (db_backup, iirc).  Have you looked in there to see if any backups were saved?  If so, they will be complete, and you should be able to import to a scratch db.
Ashes and diamonds, foe and friend,
 we were all equal in the end.

                                     - R. Waters

Novice

 Antechinus,

I finally gave up and was able to convince GoDaddy to help. It seems their new SQL servers are NOT as user friendly/compatible with any of the older SMF versions as their older servers were. This is why it would not let me do the program install like before. They did change me back to their old hosting and I paid $150.00 for a restore of the dead site. It is up and running and feel as though I gave birth as exhausted as I am. I want to thank you for all of your time and want to let everyone know that you are the Man! Thanks again!!!

Antechinus

They have probably updated their servers to use the current version of PHP, which 1.1.x can't really deal with (and it's not realistically fixable either). That shouldn't have prevented the database backup being imported though, since the database backup isn't directly affected by which version of PHP the server is running.

Anyway, it's running. Good. :)

Advertisement: