DB error during install Table 'blog_categorypermission' already exists

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Tigratrus
    Senior Member
    • Oct 2006
    • 160
    • 3.7.x

    DB error during install Table 'blog_categorypermission' already exists

    I tried to search as I think this has probably come up before but the search threw out most of the search terms as either too long, too short or too common. So my very specific search ended up searching for "exists"

    Anyway, we've been sitting on the fence on updating to vBlog 2 as we had problems on the testbed the last time, and we had some other major site update to get out the door first. Now I'm ready to start tackling this and the very first thing I get after pulling over a full, fresh copy of our site to the testbed, copying up the vBlog 2.01 P1 files and running the product xml is:

    Code:
    Database error in vBulletin 3.8.1:
    
    Invalid SQL:
    
    		CREATE TABLE blog_categorypermission (
    		  categorypermissionid INT UNSIGNED NOT NULL AUTO_INCREMENT,
    		  blogcategoryid INT UNSIGNED NOT NULL DEFAULT '0',
    		  usergroupid INT UNSIGNED NOT NULL DEFAULT '0',
    		  categorypermissions INT UNSIGNED NOT NULL DEFAULT '0',
    		  PRIMARY KEY (categorypermissionid),
    		  UNIQUE KEY usergroupid (usergroupid, blogcategoryid),
    		  KEY blogcategoryid (blogcategoryid)
    		);
    
    MySQL Error   : Table 'blog_categorypermission' already exists
    Error Number  : 1050
    Request Date  : Friday, March 6th 2009 @ 11:26:08 PM
    Error Date    : Friday, March 6th 2009 @ 11:26:08 PM
    Script        : http://www.88888888.com/forums/admincp/apm_product.php?do=productimport
    Referrer      : http://www.88888888.com/forums/admincp/apm_product.php?do=productadd
    IP Address    : 88888888888888
    Username      : Tigratrus
    Classname     : vB_Database
    MySQL Version : 5.0.67-community-log
    Suggestions?

    James and Susan

    [edit]
    I'm assuming that although I pulled over a fresh copy of the DB, the table was probably left from a prior installation on the testbed of one of the Blog 2 betas. The drop/add when I brought over a fresh copy of the DB wouldn't have removed it. I don't see the blog_categorypermission table on the live server. But I can't just dump all the blog_ tables and pull over fresh copies of just them as they would be out of synch with the rest of the vB database... Yes?
    [/edit]
    Last edited by Tigratrus; Fri 6 Mar '09, 7:45pm.
  • peterska2
    Senior Member
    • Oct 2003
    • 8869
    • 3.7.x

    #2
    Is this a new installation of the blog or an upgrade? If it is an upgrade, what version are you running at present?

    Please provide as much information as how you are doing the installation or upgrade as possible.

    Comment

    • Tigratrus
      Senior Member
      • Oct 2006
      • 160
      • 3.7.x

      #3
      Sorry Kerry-Anne... I was actually updating the op while you were posting .

      The testbed has previously had Blog2 betas on it. I pulled over a fresh copy of our entire live database and files.

      Then I upgraded from vB 3.73p1 to 3.8.1p1.

      Then I copied over all the vBlog 2.01p1 files and ran the vblog product xml through add product in the ACP.

      Then I got the error above. My speculation as to where the mystery table came from (pretty sure actually) is in the edit at the bottom of the OP.

      Is there a way out of this? Wiping the DB and starting over is a *really* painful thing with our current DB size .

      Thanks in advance for any suggestions...

      James and Susan

      Comment

      • peterska2
        Senior Member
        • Oct 2003
        • 8869
        • 3.7.x

        #4
        If you didn't restore to an empty database, then you will have tables not present in the version that you are currently running which will cause this issue. The database needs to be restored to an empty database to ensure that there are no issues.

        Comment

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