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) »
  • Partial Upgrade 3.1 to 3.4. Backup too old. Foreign keys hang up.
Pages: [1]

Author Topic: Partial Upgrade 3.1 to 3.4. Backup too old. Foreign keys hang up.  (Read 1068 times)

jhofer

  • I’m new here
  • *
  • Posts: 23
  • Karma: 0
  • CiviCRM version: 3.x
  • CMS version: Drupal 6.x
  • MySQL version: 5.x
  • PHP version: 5.x
Partial Upgrade 3.1 to 3.4. Backup too old. Foreign keys hang up.
January 02, 2013, 08:17:02 pm
I upgraded Civi from 3.1 to 3.4 about a year ago.  I recently realized it didn't upgrade completely, and I think its causing some critical errors with views2 integration. 

I'm aware of http://wiki.civicrm.org/confluence/display/CRMDOC42/Ensuring+Schema+Integrity+on+Upgrades however, there is just too much data that would be missing if I reverted to the backup I made back then.  I need to revert back to the 3.1 schema manually.  I've spent days working on this but I'm hung up on the foreign key constraints.  I've been able to DROP TABLE and ALTER TABLE DROP COLUMN to remove many of the columns that don't exist in 3.1 schema, but the foreign key thing is hanging me up.

When I try to remove columns that contain foreign keys I get the following - or similar (in phpMyAdmin):  #1025 - Error on rename of './jeremymh_actacivi_sandbox/#sql-383a_3911f5' to './jeremymh_actacivi_sandbox/civicrm_tag' (errno: 150)

When I try to drop tables with a foreign key:  #1217 - Cannot delete or update a parent row: a foreign key constraint fails

When I try to drop Index's (not sure I need to) I receive:  #1553 - Cannot drop index 'FK_civicrm_report_instance_domain_id': needed in a foreign key constraint

I realize this has more to do with mysql and not so much CiviCRM - but has anyone dealt with the whole foreign key problem and could offer me pointers?

jhofer

  • I’m new here
  • *
  • Posts: 23
  • Karma: 0
  • CiviCRM version: 3.x
  • CMS version: Drupal 6.x
  • MySQL version: 5.x
  • PHP version: 5.x
Re: Partial Upgrade 3.1 to 3.4. Backup too old. Foreign keys hang up.
January 02, 2013, 09:16:32 pm
Update:

Making headway finally with the help of SQL Manager:  http://www.sqlmanager.net/products/mysql/manager/

This allows me to remove the foreign key first then drop column...

Hershel

  • Forum Godess / God
  • I’m (like) Lobo ;)
  • *****
  • Posts: 4640
  • Karma: 176
    • CiviHosting
  • CiviCRM version: Latest
  • CMS version: Mostly WordPress and Drupal
Re: Partial Upgrade 3.1 to 3.4. Backup too old. Foreign keys hang up.
January 03, 2013, 04:47:01 am
Why can't you use the http://wiki.civicrm.org/confluence/display/CRMDOC42/Ensuring+Schema+Integrity+on+Upgrades procedure on whatever version you DO have?
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.

jhofer

  • I’m new here
  • *
  • Posts: 23
  • Karma: 0
  • CiviCRM version: 3.x
  • CMS version: Drupal 6.x
  • MySQL version: 5.x
  • PHP version: 5.x
Re: Partial Upgrade 3.1 to 3.4. Backup too old. Foreign keys hang up.
January 03, 2013, 02:41:43 pm
I have to use the procedure at the bottom of that page "How to Deal With A Partially Upgraded Database When You Don't Have a Backup"... a process of stripping away fields and tables from the 3.4 database that don't exist in the version I'm trying to revert to (3.1).  SQL Manager has a sweet database comparison feature which has made the comparison less tedious (it even creates the script for how to turn one database structure into another).

I've made the necessary drops and alters to a duplicate civicrm table.  My next steps are to disable all modules related to CiviCRM, revert to Civi 3.1 files, and point the civicrm.settings file to the reverted database (now in 3.1 schema).  If all goes well, I will try the upgrade to 3.4 again.  I'm waiting until tonight to shut down the site. 

If anyone sees any red flags in the process, please let me know!  This is my first time manipulating databases in this way (trial by fire).

CiviTeacher.com

  • I live on this forum
  • *****
  • Posts: 1282
  • Karma: 118
    • CiviTeacher
  • CiviCRM version: 3.4 - 4.5
  • CMS version: Drupal 6&7, Wordpress
  • MySQL version: 5.1 - 5.5
  • PHP version: 5.2 - 5.4
Re: Partial Upgrade 3.1 to 3.4. Backup too old. Foreign keys hang up.
January 10, 2013, 04:12:17 pm
I wrote "How to Deal With A Partially Upgraded Database When You Don't Have a Backup".   How did it go?
Try CiviTeacher: the online video tutorial CiviCRM learning library.

jhofer

  • I’m new here
  • *
  • Posts: 23
  • Karma: 0
  • CiviCRM version: 3.x
  • CMS version: Drupal 6.x
  • MySQL version: 5.x
  • PHP version: 5.x
Re: Partial Upgrade 3.1 to 3.4. Backup too old. Foreign keys hang up.
January 13, 2013, 02:12:11 pm
Hi Stoob.  Thanks so much for writing that article!  I came close to trying to contact you several times.

Well, I'm embarrassed to say I chickened out, well actually I needed to put the schema thing on hold.  I discovered that I had left a backup copy of the old CiviCRM file structure in the modules folder, which I think contributed to the problem with the upgrade.  When I removed the backup - the problem with Views (which was why I was attempting the schema cleanup and upgrade in the first place) was no longer an issue...

I will reattempt this process after my client's project deadline is safely in the past - I'll need to upgrade at some point... and I'll be sure to let you know how it goes.
Pages: [1]
  • CiviCRM Community Forums (archive) »
  • Old sections (read-only, deprecated) »
  • Support »
  • Upgrading CiviCRM (Moderator: Deepak Srivastava) »
  • Partial Upgrade 3.1 to 3.4. Backup too old. Foreign keys hang up.

This forum was archived on 2017-11-26.