No announcement yet.

Yet another upgrade problem

  • Filter
  • Time
  • Show
Clear All
new posts

  • Yet another upgrade problem

    My first attempt to upgrade to 2.0 failed miserably and I had to have my host restore my db since I did not back up. (I still have not figured out how to do that).

    Well, while I am now trying again to upgrade (still trying to figure out how to back up) I figured I'd take a peek at the next upgrade step and it tells me " We have detected that you have already tried to run the upgrade script. You will not be able to proceed unless you revert to a vB 1.1.x database..

    Yes, I DID already try to run the upgrade script, but it HAS already been reverted to a 1.1.6 DB. How can I get past this??????????? Argh... this has dragged on for 5 days.

  • #2
    That message only appears if you have a 'privatemessage' table, which, AFAIK, no hack creates -- only 2.0 does.


    • #3
      I do not follow you.

      I unsuccessfully upgraded and now want to try again. When I attempt the upgrade I get "We have detected that you have already tried to run the upgrade script. You will not be able to proceed unless you revert to a vB 1.1.x database." Thing is, I have already reverted to the 1.6 db. In fact, It was 100% resored and I am now again running 1.6.

      How can I get past this? Thanks .


      • #4
        What tables do you have in your database?

        Check phpMyAdmin or run a SHOW TABLES; query on your database.


        • #5
          What Mike is trying to ask you is what hacks have you installed on your Vb? To upgrade to version 2.0 you need to delete all hacks and the respective tables that they created, because when version 2.0 tries to install itself it adds tables as well as some great hacks. If there is already a table 'privatemessage' when version 2.0 is trying to install, you will get that error message. So best thing to do is figure out what hacks you installed and post them here. To backup and restore a database just do the following. It should be pretty self explanatory, but if you have any questions, feel free to ask.

          Download a program called putty from here
          This is what I did, and it works perfectly.

          1) Put in your ip address for your old host where it asks for your hostname. Then select the SSH radio button, and click on open, if your host supports secure telneting, if not click on telnet. It will prompt you for your login name to that server. Type in your login name and press enter, then it will prompt you for you password, type it in and press enter, and then do the following. (note) You will not see your password being typed in

          2) Then I would do a dump of your database
          mysqldump -uusername -ppassword databasename > file.sql
          3) Now download the file.sql to your hard drive.

          4) Use your FTP client to upload the file.sql to your new server in ASCII mode only!

          5) Open a new session in putty by rightclicking the top bar.

          6) Enter your NEW HOSTS ip address and select the SSH radio button then open.

          7) Now you must restore the database
          mysql -uusername -ppassword databasename < file.sql
          8) Have Fun!!

          So if my
          database name is forums
          username is steven
          password is test
          then Here is what to do.

          mysqldump -usteven -ptest forums > forums.sql
          Then upload the forums.sql to your new server in ASCII mode ONLY
          Open a new session in Putty with your NEW HOSTS IP Address, click on the SSH radio button and then open. Put your Login name and password to your new hosts server. Then when you get prompted by a $ sign type
          mysql -usteven -ptest forums < forums.sql
          Let me know how it goes.
          Hope this helps.
          Last edited by steven; Mon 28th May '01, 12:07pm.


          • #6
            *confusion level rising*

            I did not switch hosts.

            I have ZERO hacks.


            • #7
              If you want you can PM me with your server details (ip address, username password database name) and I'll take a look to see what's going on


              • #8
                <smacks self in forehead>
                If you revert to a backup, you will need to drop all the tables the 2.0 database created.

                Here's why:
                2.0 creates a table called privatemessage.
                You revert to your backup. It has syntax like this:
                DROP TABLE IF EXISTS tablename;
                CREATE TABLE tablename ( ...

                The privatemessage table never gets dropped

                So what you need to do is drop all the tables, then revert to your backup. Here's a script to drop all the tables:


                • #9
                  But if I go through all that then restore the backup, won't the same evil table still be in there?


                  • #10
                    Not if you drop it, no. And the table shouldn't be in your backup either, so that wouldn't be the problem.


                    • #11
                      I still do not follow, and here is why:

                      I attempted an upgrade from 1.6 to 2.0 (without first backing up the DB). I screwed up the upgrade process and was left with no choice but to ask my host to restore a back up from a date prior to me screwing things up. The restoration went fine and I am now using 1.6 again.

                      Now, if the host restored the DB from a backup that was PRIOR to me screwing things up with the attempted upgrade to 2.0, how could there be tables that 2.0 created? The backup is from before the upgrade attempt.


                      • #12
                        Your database contains tables a and b.

                        Your backup only references table a. Therefore, nothing in your backup has any knowledge of table b and it won't touch it.

                        So you have to empty all the (vB) tables out of your database (remove table b), and then proceed with the upgrade.


                        • #13
                          I just installed phpMyAdmin and I am now able to see what you are talking about Ed Sullivan. (I took a look at the script you referred me to, and it looked a little scary - phpMyAdmin looks more user friendly.)

                          Comparing my current database with an old db which is still there, I see an additional 23 tables (including privatemessage) which are not in the old db. The original db consists of 15 tables (all of which still appear in the current db). So, may I simply click on "drop" for each of the 23 additional tables in the current database, one at a time, until they are gone, leaving me with just 15 tables in the current database?

                          I suspect this would be the way to go. If so, one additional question please... I notice that in one of the "new" tables that I want to drop, there is a record in it. None of the other tables I plan on dropping have any records in them. The name of this table is "style", and it contains 1 record. Is it OK to drop it too?

                          Thanks so much for your help and patience.


                          • #14
                            Yes, you can just click "drop" 23 times. Or you can run a query, but I won't get into that -- clicking drop does the same thing, just a bit more tedious.

                            Yes, you can drop that table -- several of the tables would've had default records inserted into them a few steps later. That one just happened early