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

[SarahG (FountainTribe)]

I am trying to do an upgrade from 4.1.5 to 4.2.2 but at the step labeled "[Executed: Upgrade DB to 4.2.alpha1]" the status bar just waits and waits indefinitely.

Before starting the upgrade I set the 2 lines
 define( 'CIVICRM_DEBUG_LOG_QUERY', 1 );
 define( 'CIVICRM_DEBUG_LOG_QUERY', 'backtrace' );

in my file "/civicrm.settings.php" with the hopes of getting extra info in the logs.  But there are no error messages in the CiviCRM log files.

Any ideas on what to check?

[Kurund Jalmi]

Is your 4.1.5 a fresh or upgraded CiviCRM install?

Kurund

[SarahG (FountainTribe)]

Its a database that was previously upgraded. Its not a fresh install.

[Freya von Moltke-Foundation]

I seemingly ran into the same error when upgrading from 4.2.0 to 4.2.2. The upgrade hangs at the step Upgrade DB to 4.2.alpha1: Contributions (1 => 5000)
I tried that 2 times with the same result.

The error report was as follows

Error Field	Error Value
Type	DB_Error
Code	-3
Message	DB Error: constraint violation
Mode	16
UserInfo	INSERT INTO civicrm_line_item (entity_table , entity_id , label , qty , unit_price , line_total , participant_count ) VALUES ('civicrm_contribution' , 22 , 'Contribution Amount' , 1 , 100.00 , 100.00 , 0 ) [nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails (`c3_civicrm`.`civicrm_line_item`, CONSTRAINT `FK_civicrm_line_item_price_field_id` FOREIGN KEY (`price_field_id`) REFERENCES `civicrm_price_field` (`id`) ON DELETE CASCADE)]
DebugInfo	INSERT INTO civicrm_line_item (entity_table , entity_id , label , qty , unit_price , line_total , participant_count ) VALUES ('civicrm_contribution' , 22 , 'Contribution Amount' , 1 , 100.00 , 100.00 , 0 ) [nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails (`c3_civicrm`.`civicrm_line_item`, CONSTRAINT `FK_civicrm_line_item_price_field_id` FOREIGN KEY (`price_field_id`) REFERENCES `civicrm_price_field` (`id`) ON DELETE CASCADE)]

I've attached a screenshot which perhaps contains some additional information.

I remember when ugrading from 4.0.x to 4.2.0 there was the same error (at least it was about 'contributions'). But the last time the error page had a Proceed-button which turned out was safe to use. This time the button is missing

[Kurund Jalmi]

Its a database that was previously upgraded. Its not a fresh install.

Can you check for db integrity before upgrading to 4.2.x. I would try following

- take a db back of CiviCRM v4.1.x
- mysqldump only data
- drop the db
- create db with structure from sql/civicrm.mysql
- import previously exported data using mysqldump
- logout /login to civicrm.
- make sure 4.1.x works and then try upgrade.

HTh
Kurund

[CiviTeacher.com]

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...

Issue 2: 4.2.alpha1, when it stalled again.  I left for 1 hour, and returned, and reloaded the page.  That's when I got this error

ALTER TABLE `civicrm_prevnext_cache` ADD COLUMN is_selected tinyint(4)
DEFAULT '0' [nativecode=1060 ** Duplicate column name 'is_selected']

I dropped the db, loaded it again, tried upgrade again with the same error, same result. 

I have not yet tried the schema integrity check, but it seems if this is_selected is a new column for 4.1 or 4.2, then why should it error?

Would it help to upgrade to 4.1 FIRST and then a subsequent upgrade to 4.2?

Any other ideas?

[andersiversen]

I also have this error, upgrading from 4.1.3 to 4.2.4 - it hangs at Upgrade DB to 4.2.alpha1: Contributions (1 => 5000).

(I guess it's a minor detail, but it shouldn't say alpha1 should it?)

[CiviTeacher.com]

Does anyone in this thread have the modules jQuery Update, jQuery UI, or another module that does something with jQuery installed?

[kindermaur]

I have the same problem, upgrading from 4.0.7 on drupal 7.x. I'll try troubleshooting/debugging this weekend.

And no jQuery modules installed.

[kindermaur]

It looks like the upgrade gets through the first part of the update to 4.2.alpha1, in that all the database changes in this file:

civicrm/CRM/Upgrade/Incremental/sql/4.2.alpha1.mysql.tpl

were made to the database. So it hangs somewhere after this... hopefully that helps.

Are there any logs that would show more detailed progress of the upgrade?

[raviskiran]

Any progress on this ..I face the same issue.

[bradb]

Just my 2 cents on upgrading, it may help. The first thing I would do is make sure the integrity of the database schema is up to date for the version you currently have installed. Kurund points out this step below as well. But this is the absolute best way to know that what your trying to upgrade is in a good state. Instructions for this step can be found here:

http://wiki.civicrm.org/confluence/display/CRMDOC42/Ensuring+Schema+Integrity+on+Upgrades

Secondly...I have done many civicrm upgrades from various version. It can be difficult and patience is a virtue. I would advise against trying to do large jumps in 1 swoop. IE 3.4.8 to 4.2.2. In my experience doing smaller jumps seems to breed less frustration. The reason being, smaller jumps introduces less changes to the database. I have had much more success doing upgrades more incrementally.

99% of the time I have experienced an error it has some way or another been related to a foreign key constraint. Often times my best course of action was to check the civicrm domain table after a failed upgrade and checking where the upgraded stopped. Then I would go in to that .sql file and comment out the part where the error is coming in. After I got through those errors and at least got my civi install up to the version I wanted, I would ensure the schema by using the method above.

Finally just a couple notes to keep in mind for people managing civi sites. CiviCRM 4.2.4 is the first version to no longer support php 5.2. This means if your joomla/drupal/wp site was built on a system with php 5.2, civi 4.2.2 is the highest you will be able to upgrade to unless you redo your site in php 5.3. This does not require a full rebuild of the site but is still kind of a pain and its a good thing to think about beforehand. Also with civi 4.2.4 a higher level of database privilege is now required to run the db upgrade. If not properly permissioned you will get an error saying that you need a 'Super' privilege to execute the upgrade. This can pose problems on shared hosts such as godaddy or network solutions as you can't get this level of access. I had to use a personal wamp installation to get a few sites from 4.2.2 to 4.2.4. Food for thought.

[ev_blurbs]

I had the exact same frustrating problem. If it stalls on Upgrade DB to 4.2.alpha1, check your console and see if you are getting a 504 Gateway Timeout error. If you are, you can try disabling your Reserve Proxy Server (nginx) and get a more detailed error message. Mine was saying an error message related to "MYSQL server has gone away". This was due to the less than adiquate settings in place on my Media Temple server. You can find these settings in a file called my.cnf (located at /etc/my.cnf for me). I followed the first part of this tutorial on optimizing the settings in my.cnf file: h t t p : / / wiki.mediatemple.net/w/(dv)_4.0_-_Making_It_Better_::_General_MySQL_Tuning (link broken to allow me to post). It resolved the issue for me.

[b0b_z]

We're having the same problem
Running 4.1.5 under drupal 7.19

I've tried in the past and have the progress bar hang at about 10% and that's it

Did a restore and got it back working

I tried the incremental upgrade and was successful from 4.1.5 to 4.1.6

Any suggestions?

Thanks!

[SarahG (FountainTribe)]

I have solved this in my environment.

Here is what I tried first ( per Kurund's suggestion on this thread, as this was not a fresh install)
- take a db back of CiviCRM v4.1.x
- mysqldump only data
- drop the db
- create db with structure from sql/civicrm.mysql
- import previously exported data using mysqldump
- logout /login to civicrm.
- make sure 4.1.x works and then try upgrade.

These steps had no impact on my issue. The upgrade hung at the same point as before.


What I did next: At the point at which the upgrade was hanging in the browser, I re-ran the URL in the address bar ( ie http://mygroup.org/civicrm/upgrade/queue/runner?reset=1&qrid=CRM_Upgrade )     Then I saw an actual error message and stack trace.

What I realized from investigating the stack trace, is that CiviCRM was trying to re-execute the SQL file: /CRM/Upgrade/Incremental/sql/4.2.alpha1.mysql.tpl    which was failing because at this point the db was partially upgraded. 
The thing I did that finally allowed the upgrade to run successfully:  I restored the database to a clean version of 4.1.5,  then I commented out the following SQL from file '/CRM/Upgrade/Incremental/sql/4.2.alpha1.mysql.tpl'  :

Code: [Select]

ALTER TABLE `civicrm_mailing_recipients` ADD `phone_id` int(10) unsigned DEFAULT NULL;

ALTER TABLE `civicrm_mailing_recipients` ADD CONSTRAINT `FK_civicrm_mailing_recipients_phone_id` FOREIGN KEY (`phone_id`) REFERENCES `civicrm_phone` (`id`) ON DELETE CASCADE;

ALTER TABLE `civicrm_mailing_event_queue` ADD `phone_id` int(10) unsigned DEFAULT NULL;

ALTER TABLE `civicrm_mailing_event_queue` ADD CONSTRAINT `FK_civicrm_mailing_event_queue_phone_id` FOREIGN KEY (`phone_id`) REFERENCES `civicrm_phone` (`id`) ON DELETE CASCADE;

ALTER TABLE `civicrm_mailing_event_queue` CHANGE `email_id` `email_id` int(10) unsigned DEFAULT NULL;
ALTER TABLE `civicrm_mailing_recipients` CHANGE `email_id` `email_id` int(10) unsigned DEFAULT NULL;


After the CiviCRM upgrade process completed successfully, I ran those SQL statements from within PhpMyAdmin. 

In my database each of those 2 tables have over 200,000 records and the SQL statements took a while to complete.   I think the automated upgrade process was timing out on these long-running SQL statements.  What would be helpful is if the upgrade process submitted any potentially long-running SQL to a background thread. Or at least reported some kind of error message.

Hope this is helpful.