Upgrade 7.2 Failed - duplicate column name

Upgrading from 7.1.9 to 7.2.

Followed steps indicated on upgrade instructions.

Upgrade scrip ran fine until it got to the next query after "poll module language strings were successfully added." 

This error appeared so I did not get to the end of the procedure. How can I get past this.

ALTER TABLE `bx_groups_main` ADD `allow_view_forum_to` varchar(16) NOT NULL AFTER `allow_post_in_forum_to`;: Duplicate column name 'allow_view_forum_to' 

site is http://molosserdogs.com

 you mean 7.1.6 > 7.2.0 i see on your site olso your templates are maching 7.1.6 only not the 7.2.0 version

you have set uni template before the upgrade script starting 

If this is the first time you have applied the upgrade patch, then something else must have added the column allow_view_forum_to, to the bx_groups_main table. 

Hi GG,

Yes you are right 7.1.6 to 7.2.

This is the first run of the upgrade script. I may have to look at the upgrade script and see if I can manually do the rest of the upgrade.

The site seems to work ok but will throw and Db error  when I try to preview a theme.  I don't think anything after the Poll upgrade happened.

It fails on the modules>groups>sql.sql file.   I have ultimate groups module installed.  I wonder if I removed the affected table and ran the upgrade script again if it will kill my site. 

Any suggestions?

My guess is that the ultimate groups module added the column.  That column may contain data so you don't want to remove the column if that is the case.  I would alter the install sql so that it is not trying to add the column.  The install sql script should have anticipated that the column might exist.

The question I now have is that if the patch install sql added other columns that rerunning the install patch would result in similar errors?  The install script sql should skip any columns that already exists when it tries to create a column.

So my suggestion is to remove the part in the sql that tries to add the column and then rerun the patch.

By the way, one should not run the upgrade patch on a live site without first running it on a clone of the site; I can not stress that enough.  If you don't, you risk bonking a live site and it could be down for some time while you try to repair it.

so true. I make a backup before the upgrade.  I don't have a sandbox so here goes. :)

I was not properly paying attention; you said you had Ultimate Groups installed.  The upgrade script is thinking you have the Boonex Groups module installed.  If all it wanted to do was add that one column then probably no harm.  However, you would not want the patch making changes to the Ultimate Groups module.

You really need to ask Modzzz what you're supposed to do about his "Ultimate Groups" module, in the support topic for it.  He should be the one responsible for providing a modified upgrade script, because it's a pretty crappy situation to put people in.  If he's going to sell a mod that alters core files and db tables, that makes running the upgrade script impossible, he should be the one to provide the work-around.

I'm having the same problem.  I have Premium Events and Premium Groups.  I deleted the 'allow_view_forum_to' column in my database before running the upgrade.  It added the column, but still gave me the same error message and the script quit.  I've sent a PM to Modzzz.

I added a field to a database table for the groups module. How should I know that years ahead after I release a module boonex would release an upgrade that tries to add the very same field ? As geekgirl says, the upgrade script should really check if the field exists before trying to add it.

From the description on your Premium Groups module that says it is compatible with Dolphin 7.2 :

"Enhanced so that Group Admin can choose who have viewing access to the forum."

As you know, Dolphin 7.2 adds this feature (You can actually thank me for that... I added the ticket to trac :)"

So I guess your premium groups module isn't really compatible with 7.2, regardless of what boonex named the fields.  Looks like you have a situation, but that's what happens when you have a module that alters core db tables.  I'm confident that you'll have this fixed in no time.

I will provide an update later tonight on renaming the field before doing the update. However, I am not sure about continuing the update after it has stopped. AlexT has to shed some light on that.

This has nothing to do with the Dolphin 7.2 version of the module. The issue is with persons who have the Dolphin 7.1 version installed and are trying to upgrade their site.

The description of your module states that it adds a feature that already exists, as of 7.2.  I call that an incompatibility. What would you call it?

It was a slow Sunday.... so here goes.

Well - I made some modifications (basically ran the upgrade/files/7.1.6-7.2.0/modules/*/sql.sql files in phpmyadim) and removed the offending lines of code in mysql. I also removed the offending duplicate statements from upgrade\files\7.1.6-7.2.0/sql.sql changed version in header.ince to 7.1.6 and reran the upgrade script.  

All went well until the photo resizer timed out because it was processing 30 photos at a time... I then changed \upgrade\files\7.1.6-7.2.0/photo_resize.php line 20 from "    $iLimit = 30;" to "    $iLimit = 10;" and the photoresizer ran to completion... 

So - my site is upgraded.... Yeah.. now to reconfiger because my blocks were changed with is not cool.

Why does an upgrade mess with the blocks and default order of things - weird!

http://molosserdogs.com only for dog lover.... :)

It seems to be that this upgrade has been a huge mess for a lot of users.  There is a reason I am sitting back and waiting and watching others perform the upgrade.  7.2 was released too early; I could tell there was still issues to work out but Boonex ploughed ahead and released it anyway.  There should have been at least one more beta release.  Now it appears that the upgrade script was not tested enough as well.

If upgrade script didn't completed due to some errors, then it's not safe to leave it as it is, upgrade script have to be completed or site behaviour could be unpredictable. 

Here are the steps on how to fix upgrade errors:

http://www.boonex.com/forums/topic/Errors-fixing-procedures-during-upgrade.htm

Modzzz,

Did you create a fix yet for this upgrade issue?

It happens to me just today it's stop in groups having duplicate error, but i manage to run sql manually one by one inside the upgrade file

I go here first http://www.yoursite.com/administration/modules.php

Check all default module with version version 1.1.6

And run SQL in phpmyadmin (advanced user only) inside the module folder and choose specific mod and open it has sql file, do it all manually to upgrade default module to 2.0.

After that open this file

http://www.yoursite.com/upgrade/files/7.1.6-7.2.0/conclusion.html

Follow instructions.

Bit of work but hope it helps.

Expertzkris,

Man, those were thorough instructions.  I really appreciate it.  I'll try it out and see if I have any luck.

Thanks again.

Please backup database beforehand just for security :) Enjoy!

 That was written in 2012 and talking about 7.0.9 to 7.1.0 upgrade.

Is it still valid?

Upgrade Hell 7.1.6 to 7.2.0

Edit - Following the steps and it's making sense. The best solution is to restore site from backup, fix the problem and run upgrade script again.

Delete already upgraded modules from /upgrade/files/7.1.6-7.2.0/modules/ folder.

As mentioned above, SiteURL/administration/modules.php (version 1.2.0 by Boonex is upgraded, version 1.1.6 by Boonex is not).

I'm reading (trying to read) the sql.sql scripts as I go and hopefully can gain a better understanding of how it all works under the bonnet. It's like learning Hungarian.