CiviCRM Community Forums (archive)

*

News:

Have a question about CiviCRM?
Get it answered quickly at the new
CiviCRM Stack Exchange Q+A site
This forum was archived on 25 November 2017. Learn more.
How to get involved.
What to do if you think you've found a bug.



  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Support »
  • Upgrading CiviCRM (Moderator: Deepak Srivastava) »
  • Upgrading from 4.2.8 to 4.3.5 ... not working
Pages: [1]

Author Topic: Upgrading from 4.2.8 to 4.3.5 ... not working  (Read 1485 times)

pdelbar

  • I post occasionally
  • **
  • Posts: 51
  • Karma: 3
  • Web integrator, Joomla freak, CiviFan
    • delius.be
  • CiviCRM version: 4.2.6/7
  • CMS version: Joomla 2.5.7 / 3.0
  • MySQL version: 5.1
  • PHP version: 5.3
Upgrading from 4.2.8 to 4.3.5 ... not working
September 05, 2013, 06:21:18 am
I'm doing an upgrade from 4.2.8 (in Joomla, but that's irrelevant) using the standard method as described. The code upgrade runs fine, but when I do the DB upgrade, I run into issues. The DB structure is clean, I compared it to a clean 4.2.8 install and it is identical.

First issue I have is that I get

ALTER TABLE `civicrm_financial_type` CHANGE `name` `name` varchar(64) COLLATE utf8_unicode_ci NOT NULL COMMENT 'Financial Type Name.', ADD CONSTRAINT `UI_id` UNIQUE INDEX(id), DROP INDEX UI_name [nativecode=1091 ** Can't DROP 'UI_name'; check that column/key exists]

OK, I can fix that, reload the database, start again after fixing the indexes so this does not crash. Next, I get

ALTER TABLE `civicrm_entity_financial_account` ADD CONSTRAINT `FK_civicrm_entity_financial_account_financial_account_id` FOREIGN KEY (`financial_account_id`) REFERENCES `civicrm_financial_account` (`id`) [nativecode=1005 ** Can't create table 'staging_apopo_site_cms.#sql-82e6_313' (errno: 121)]

This is on a local machine with root privileges.

Has anyone else seen such behaviour ?

Hershel

  • Forum Godess / God
  • I’m (like) Lobo ;)
  • *****
  • Posts: 4640
  • Karma: 176
    • CiviHosting
  • CiviCRM version: Latest
  • CMS version: Mostly WordPress and Drupal
Re: Upgrading from 4.2.8 to 4.3.5 ... not working
September 10, 2013, 10:50:29 am
Yes, sometimes such errors occur with upgrades. You can either trace through the code and find where that is and remove it OR you can try this: http://wiki.civicrm.org/confluence/display/CRMDOC/Ensuring+Schema+Integrity+on+Upgrades
CiviHosting and CiviOnline -- The CiviCRM hosting experts, since 2007

See here for the official: What to do if you think you've found a bug.

benmoreassynt

  • I post occasionally
  • **
  • Posts: 52
  • Karma: 0
  • CiviCRM version: 4.4.4
  • CMS version: Joomla 2.5.19/Wordpress 3.8
  • MySQL version: 5.5.35
  • PHP version: 5.3.10
Re: Upgrading from 4.2.8 to 4.3.5 ... not working
September 15, 2013, 12:33:37 pm
Hi - having an almost identical problem (I've run into this on my last two CiviCRM upgrades).

I've tried the solution on http://wiki.civicrm.org/confluence/display/CRMDOC/Ensuring+Schema+Integrity+on+Upgrades which has worked for me in the past, however it is not working for me this time. I still run into the following error:

Code: [Select]
ALTER TABLE `civicrm_discount` ADD CONSTRAINT `FK_civicrm_discount_price_set_id` FOREIGN KEY (`price_set_id`) REFERENCES `civicrm_price_set` (`id`) ON DELETE CASCADE [nativecode=1452 ** Cannot add or update a child row: a foreign key constraint fails (`civicrm-new`.`#sql-2c5c_996`, CONSTRAINT `FK_civicrm_discount_price_set_id` FOREIGN KEY (`price_set_id`) REFERENCES `civicrm_price_set` (`id`) ON DELETE CASCADE)
Being still somewhat unfamiliar with InnoDB constraints, could someone suggest to me how I can manually resolve such key conflicts? I've tried various solutions such as adding 'SET FOREIGN_KEY_CHECKS = 0', to the upgrade SQL but with no success.

Hershel

  • Forum Godess / God
  • I’m (like) Lobo ;)
  • *****
  • Posts: 4640
  • Karma: 176
    • CiviHosting
  • CiviCRM version: Latest
  • CMS version: Mostly WordPress and Drupal
Re: Upgrading from 4.2.8 to 4.3.5 ... not working
September 15, 2013, 12:55:00 pm
Seems to me that you have a missing price_set_id in the civicrm_price_set table. Did you delete one? Easiest thing might be to make a fake record manually, for the upgrade, and then remove it after.
CiviHosting and CiviOnline -- The CiviCRM hosting experts, since 2007

See here for the official: What to do if you think you've found a bug.

benmoreassynt

  • I post occasionally
  • **
  • Posts: 52
  • Karma: 0
  • CiviCRM version: 4.4.4
  • CMS version: Joomla 2.5.19/Wordpress 3.8
  • MySQL version: 5.5.35
  • PHP version: 5.3.10
Re: Upgrading from 4.2.8 to 4.3.5 ... not working
October 14, 2013, 01:09:24 pm
Apologies for slow reply.

This was exactly the problem. Adding a 'fake' entry to the table referenced by the foreign key, using the correct key id, enabled a smooth upgrade to complete (using the default DB upgrade tool, rather than the workaround).

Many thanks.

e_mason

  • I post occasionally
  • **
  • Posts: 65
  • Karma: 1
  • Eliot Mason
  • CiviCRM version: 4.05
  • CMS version: Drupal 7
  • MySQL version: 5.1xx
  • PHP version: 3.53
Re: Upgrading from 4.2.8 to 4.3.5 ... not working
February 23, 2015, 09:40:15 am
In upgrading a client's system from 4.2.16 to 4.5x I couldn't get the upgrade past the 4.3Alpha1 steps - there were several tables that failed the foreign key creation.  It turns out that the tables already existed, but were truncated with no records.  Thus the "Create if not exists" SQL statements  weren't run, thus no viable records for the foreign key creation.

By deleting tables, the upgrade could both create and populate the tables.  Once done, the upgrade proceeded.

The sql statements I used:

drop table civicrm_financial_type;
drop table civicrm_entity_financial_account;
drop table civicrm_financial_item;
Pages: [1]
  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Support »
  • Upgrading CiviCRM (Moderator: Deepak Srivastava) »
  • Upgrading from 4.2.8 to 4.3.5 ... not working

This forum was archived on 2017-11-26.