Announcement

Collapse
No announcement yet.

Downgrading from 4.0 To 3.84 (database dump problems)

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Ingenious
    replied
    Supergper - many thanks for that info, appreciated

    Leave a comment:


  • supergper
    replied
    Also, if all of your files do say 3.8.4 at the top of them, then run the finalupgrade.php script. It's located in the install/ directory.

    Leave a comment:


  • supergper
    replied
    Open up some of your .php files and see what version they say they are. They should say at the top that they are 3.8.4 PL2 (assuming you've updated to PL2).

    Leave a comment:


  • Memphis834
    replied
    Thanks for all your help Supergper! Right now got the site back up and running. There's still a few things I'm working though. My seo is all screwed up. I installed seo so long ago I'm having trouble getting my site back to the seo urls but I'm not so much worried about that as I am worried about this issue with my admincp. No matter what I do, I can't seem to fix it. As it stands right now, it's like site is a combination of both 4.0 and 3.8.4. The top says "Admin Control Panel (vBulletin 3.8.4 Patch Level 2)" and is just how it was before I got myself in this mess. The only difference is I can't see the control panel home, the bottom of my forum lists as 'vbulletin 4.0', and all my database errors list as 4.0. I've deleted everything, and only used 3.8.4 files yet when I log into my admincp, it gives me a database error message for 4.0:

    Database error in vBulletin 4.0.0:

    Invalid SQL:

    SELECT COUNT(*) AS count
    FROM attachment AS attachment
    INNER JOIN post AS post USING (postid)
    WHERE attachment.visible = 0;

    MySQL Error : Unknown column 'postid' in 'from clause'
    Error Number : 1054
    I tried: Admincp> Diagnostics > Suspect File versions (This function will list each of your vBulletin files that is tagged with a different version than your forum is currently at, which is 4.0.0.)

    And this is what lists for the admin files: File not recognized as part of vBulletin

    I just can't seem to get my admincp to list as 3.8.4

    Leave a comment:


  • supergper
    replied
    Originally posted by Ingenious View Post
    I had similar problems restoring my sql dump on a new host, because the exact syntax/format of the "mysql" command in SSH is NOT the same on every server, you are best asking your host for the exact format of command to use. In my case the password parameter was different causing it to prompt me for the password again then give an error.

    On my old host it was:

    mysqldump -u USERNAME -p DATABASENAME --host=HOSTNAME > /path/to/your/file.sql
    which prompted me for password manually.

    On my new host it is:

    mysqldump -u USERNAME -pPASSWORD DATABASENAME -h HOSTNAME > path/to.filename.sql

    note there is NO space between -p and the password!

    To restore you will need to change mysqldump to "mysql" and > to <

    Also I am not sure what you need to change for a gz file as I never use it. But I hope the above is some use, really just posting to demonstrate there are differences in syntax and you could try using the password in the command.

    Finally as posted above, the < is wrong in the original command, it should be > Can I suggest you download the dump to your pc, extract it then check it in a text editor to make sure it is a proper dump? Is it possible your original back up is at fault?
    Wrong, mysql syntax is the same on every host. The only reason SSH commands may be slightly different (nothing to do with the mysql commands) is based on what shell your host is having you use (and you should be able to change this...that another issue for another thread). Your MySQL statements are both correct, and both would work on both hosts. I'll explain them real quick:

    mysqldump -u USERNAME -p DATABASENAME --host=HOSTNAME > /path/to/your/file.sql

    This one you're not specifying the password in the command. This is the preferred method because otherwise, if by chance someone were to get access to your server, they can get your password just simply by looking at your history. The --host=HOSTNAME is correct way to do it. However, you shouldn't need to specify your host unless your mysql instance is not on the same server/vps/host as your web server (basically, if you can't just say localhost for the host, then you'll need to specify your HOSTNAME).

    mysqldump -u USERNAME -pPASSWORD DATABASENAME -h HOSTNAME > path/to.filename.sql

    This one will work on any host as well, and you are correct, -p<password> does not have a space between the -p and the password, but I'd suggest against ever using the password in your command lines. The -h HOSTNAME is another way to specify the host, but as I said above, you shouldn't need to specify the host unless you have multiple servers, or can't specify the host as localhost.

    MySQL syntax is the exact same no matter what OS you are running, no matter what shell you are running, and no matter what web host you are using. All of the MySQL syntax is very well documented, if you type mysql --help it will spew all the options back at you. You'll see what each thing does.

    Leave a comment:


  • supergper
    replied
    Originally posted by Memphis834 View Post
    Back again, you all are probably sick of me at this point. I tried this (I believe what supergper was suggesting):

    mysql -u bleedani_hiphop -p bleedani_nationofhiphop < /root/bleedani_nationofhiphopthisone.sql.gz

    Then it asked me for my password, I entered it. Then I received this error message:

    You're close. To restore it, you need a .sql file. So you need to gunzip it:

    gunzip /root/bleedani_nationofhiphopthisone.sql.gz

    Then to restore it, do what you tried:

    mysql -u bleedani_hiphop -p bleedani_nationofhiphop < /root/bleedani_nationofhiphopthisone.sql

    This is assuming your mysql username is bleedani_hiphop and the database you want to restore to is bleedani_nationofhiphop.

    Also, as mentioned, you may want to drop the existing tables, or even the entire database so you aren't left with unnecessary tables and columns that were created by upgrading to 4.0.

    mysql -u bleedani_hiphop -p
    drop database bleedani_nationofhiphop;
    create database bleedani_nationofhiphop;

    This will log you in to MySQL, let you crop the database and then create an empty an empty database. Then you can exit MySQL and run the import I showed you above. That should all work. You should be able to just cut and paste everything.

    Leave a comment:


  • Ingenious
    replied
    I had similar problems restoring my sql dump on a new host, because the exact syntax/format of the "mysql" command in SSH is NOT the same on every server, you are best asking your host for the exact format of command to use. In my case the password parameter was different causing it to prompt me for the password again then give an error.

    On my old host it was:

    mysqldump -u USERNAME -p DATABASENAME --host=HOSTNAME > /path/to/your/file.sql
    which prompted me for password manually.

    On my new host it is:

    mysqldump -u USERNAME -pPASSWORD DATABASENAME -h HOSTNAME > path/to.filename.sql

    note there is NO space between -p and the password!

    To restore you will need to change mysqldump to "mysql" and > to <

    Also I am not sure what you need to change for a gz file as I never use it. But I hope the above is some use, really just posting to demonstrate there are differences in syntax and you could try using the password in the command.

    Finally as posted above, the < is wrong in the original command, it should be > Can I suggest you download the dump to your pc, extract it then check it in a text editor to make sure it is a proper dump? Is it possible your original back up is at fault?

    Leave a comment:


  • Sir Nick
    replied
    Originally posted by Trevor Hannant View Post
    If you're restoring an old database, make sure you do so to a new empty one or to the existing database only after you've dropped all the existing tables within it.
    Lol yep thats what i did when i improted vb 4 database into a 3.8 forum. :P took about 2-3 hours to get everything fixed but i got it fixed . Also I love your avatar.

    Leave a comment:


  • Trevor Hannant
    replied
    If you're restoring an old database, make sure you do so to a new empty one or to the existing database only after you've dropped all the existing tables within it.

    Leave a comment:


  • Memphis834
    replied
    Back again, you all are probably sick of me at this point. I tried this (I believe what supergper was suggesting):

    mysql -u bleedani_hiphop -p bleedani_nationofhiphop < /root/bleedani_nationofhiphopthisone.sql.gz

    Then it asked me for my password, I entered it. Then I received this error message:

    ERROR 1064 (42000)at line 1: 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 '

    Leave a comment:


  • icarusforde
    replied
    but I must be the worst SSH user of all time because nothing I do with SSH seems to work.
    You're not quite there. At least you know what SSH is - my other admin doesnt even know what it stands for/does/is/why we need it. :P

    (That being said, i'm not exactly fabulous with it myself...)

    Leave a comment:


  • Memphis834
    replied
    Hello everyone, thanks for the replies. I had already done a database backup prior to the upgrade. I don't need to do another backup so my use of mysqldump terminology might be incorrect. Basically I have a backed up database that I want to restore. I've been in contact with my VPS provider again, they told me the following: Try repairing the database via your script backend

    I wasn't sure how to go about doing that so I asked them how I would do this and they told me to install phpmyadmin. They gave me this link:
    http://securesignup.net/vps-videos/i...-vps/index.htm

    I tried going by those instructions but I must be the worst SSH user of all time because nothing I do with SSH seems to work.

    Leave a comment:


  • supergper
    replied
    FWIW, your dump syntax is wrong. It should be something like:

    mysqldump -u <username> -p <dbname> > <dir you want dbfile>.sql

    You can then GZip it by issuing a:

    gzip <dbfile.sql>

    In the original dump, you notice the > sign. You have < in yours which is trying to restore the backup (< puts it back in, > dumps it out to a file). Hope that helps.

    Leave a comment:


  • Alan_SP
    replied
    Originally posted by Memphis834 View Post
    Would anyone be willing to assist me with this if I provided them with my server information via PM? At this point I'm rather desperate for help as I can't seem to fix this problem.
    You could try to go through cPanel, phpMyAdmin. First, you create empty database (to maybe restore damaged one later). Then, using phpMyAdmin select new empty database. Import file from your computer (that should restore your backup database). Upload files from your computer, change config.php to point to new database and user (oh yes, you need to create and add user to new database) and that should be it.

    Leave a comment:


  • Lats
    replied
    I missed the tarred up datafile, oops. Try this...
    Code:
    gunzip bleedani_nationofhiphopthisone.sql.gz
    That should leave you with the standard .sql file.

    Leave a comment:

widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
Working...
X