Upgrade to 4.2.2 just hangs at step [Executed: Upgrade DB to 4.2.alpha1]

[Mark Tompsett]

I encountered the same problem, ie upgrade process just hangs, when trying to upgrade a 3.4.8 to 4.2.8 and fuond this thread very helpful.
In my case I initially upgraded to 4.1.3 (which was fine) then to 4.2.8 (which was also fine).

Mark   

[Shai]

I also had the same problem, hang on update from 4.1.6 to 4.2.9.

I followed the instructions in @epg's post: http://forum.civicrm.org/index.php?topic=26432.msg117328#msg117328

But note, you can't use

Code: [Select]

/* and */ to comment out the queries that will be run manually because that file is not a php file. I deleted the those queries. After the successful upgrade I ran the queries manually at the command line.

[Upperholme]

Just wondering if this issue ever got properly identified and resolved?

I'm in the midst of trying to upgrade a site from 3.47, and came up against this issue. I got the site upgraded without a problem from 3.4.7 to 4.1.5 (I ran the db through the schema integrity process before trying the upgrade), but could when trying to go from 4.1.5 direct to 4.3.3 it did not want to play.

Now I'm going in smaller steps. worked fine to 4.1.6, and now trying to go up to 4.2.1. The upgrade script reported that I need to edit civicrm.settings.php (which I didn't expect) to add a couple of lines, but then hung at the 4.2 alpha1 stage as others have reported. I refreshed the page and it all seemed to go through, no errors reported as far as I can see, but it certainly does not fill me with confidence.

[CiviTeacher.com]

Ran into this issue again going from 4.1.6 to 4.3.5.  Schema integrity procedure fixed the problem.

[alanpuccinelli]

Same boat as EPG.
Database was timing out on updates to the civicrm_mailing_recipients table (nearly 10M rows). It gave up on the Alter Table statements too quickly and then tried to re-run everything eventually kicking out an error when it tried to recreate an Index that already existed. This can probably be allieviated by upping the timeouts for each statement but for the time being I just manually updated the DB for the statements relevant to that table and commented out the statements in the 4.2.alpha1.mysql.tpl file with double dashes and re-ran the update. Worked fine after that. If you're seeing Duplicate column name errors there's a good chance something is timing out when you're running the DB upgrades. For help troubleshooting consider temporarily enabling the general query log and then look for where the updates stop and attempt to re-run.

[mariolita]

I can confirm a similar experience on an upgrade from 3.4.8 to 4.2.2.

Issue 1: The process stalled at 4.1.beta, and I left it running overnight.   When I reloaded the page in the morning, the upgrade proceeded without error until...