Announcement

Collapse
No announcement yet.

Downgrading from 4.0 To 3.84 (database dump problems)

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

  • #16
    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.
    Vote for:

    - *Admin Settable Paid Subscription Reminder Timeframe*
    -
    *PM - Add ability to reply to originator only*
    - Add Admin ability to auto-subscribe users to specific channel(s)
    - "Quick Route" Interface...

    Comment


    • #17
      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.

      Comment


      • #18
        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?
        Fireworks

        Comment


        • #19
          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.

          Comment


          • #20
            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.

            Comment


            • #21
              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

              Comment


              • #22
                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).

                Comment


                • #23
                  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.

                  Comment


                  • #24
                    Supergper - many thanks for that info, appreciated
                    Fireworks

                    Comment

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