CiviCRM Community Forums (archive)

Hello, greetings, salutations

During my upgrade to 3.0.4 from 2.2.8 I have realised that one of my older updates did not go completely through and hence the update from 2.2.8 to 3.0.4 didn't want to go through, either.
Approach that I generally took to fix this issue was to dump data, diff the schema dumps and fix the discrepancies manually.
Then I was able to go to 3.0.4 from 2.2.8

Since 2.2.8 went to 3.0.4 I was optimistic about going from 3.0.4 to 3.1.2, but got an error..
Then I have run civicrm.sql from 3.0.4 and restored data that I have on top of that and made sure that schemas are the same. But still I get...

   Sorry. A non-recoverable error has occurred.

    DB Error: constraint violation

    Database Error Code: Column 'option_group_id' cannot be null, 1048

    Return to home page.

Error Details:

Array
(
    [callback] => Array
        (
            [0] => CRM_Core_Error
            [1] => handle
        )

    [code] => -3
    [message] => DB Error: constraint violation
    [mode] => 16
    [debug_info] => INSERT INTO
   `civicrm_option_value` (`option_group_id`, `label`, `value`, `name`, `grouping`, `filter`, `is_default`, `weight`, `is_optgroup`, `is_reserved`, `is_active`)
VALUES(@option_group_id_cdt, 'Participant Event Type', '3', 'ParticipantEventType', NULL, 0, NULL, 3, 0, 0, 1) [nativecode=1048 ** Column 'option_group_id' cannot be null]
    [type] => DB_Error
    [user_info] => INSERT INTO
   `civicrm_option_value` (`option_group_id`, `label`, `value`, `name`, `grouping`, `filter`, `is_default`, `weight`, `is_optgroup`, `is_reserved`, `is_active`)
VALUES(@option_group_id_cdt, 'Participant Event Type', '3', 'ParticipantEventType', NULL, 0, NULL, 3, 0, 0, 1) [nativecode=1048 ** Column 'option_group_id' cannot be null]
    [to_string] => [db_error: message="DB Error: constraint violation" code=-3 mode=callback callback=CRM_Core_Error::handle prefix="" info="INSERT INTO
   `civicrm_option_value` (`option_group_id`, `label`, `value`, `name`, `grouping`, `filter`, `is_default`, `weight`, `is_optgroup`, `is_reserved`, `is_active`)
VALUES(@option_group_id_cdt, 'Participant Event Type', '3', 'ParticipantEventType', NULL, 0, NULL, 3, 0, 0, 1) [nativecode=1048 ** Column 'option_group_id' cannot be null]"]
)
Grep shows that @option_group_id_cdt is set to max(id) from civicrm_option_group where name = 'custom_data_type' (in civicrm/CRM/Upgrade/Incremental/sql/3.1.beta2.mysql.tpl)

However my custom data types in civicrm_option_group do not have name 'custom_data_type', they have individual names.

So, obviously not only schema changed, there was some data processing that I didn't take into account.
Any pointers on what to look at?

P.S. I assume that one of my previous backups went wrong - in this case may I may I propose a simple change to the upgrade process?
If I understand correctly version goes from current to upgraded, and this is done towards the start of the process - since the upgrade is not atomic, could we have version numbers go current, unusable-update-in-progress-version-code and only when everything is successfully upgraded set it to new version. Then if the system remains in upgrade interrupted state civicrm would recognize and would not allow system to be used  (or at least keep a big red warning on every page - upgrade in progress). If I realized my mistake at that time I would have gone to the backups and tracked the error down. This way... it is not really an interesting option. Sorry for a long post.[/code]

i think your idea of marking the version field as UPGRADE-3.1-3.2 is quite excellent and we should do it

can you please file an issue and we'll take care of this in the next release

thanx

lobo

2 issues here as pointed out in the previous.  Clear notification of a incomplete upgrade or a fully successful upgrade.

I also did install from 3.0.4 to 3.1.2 and for a while though I had a completed the upgrade but was not sure. I just used the package installer in Joomla.  I got a screen for files where successfully updated with a link to upgrade the database. I clicked it and said upgraded to 3.0.0 which was the correct status but no for the db when the files had been changed. I was unsure the db then needed the upgrade and looked through the system. But noticed there was no new dashboard etc. improvements that where said to be in the upgrade. When going to the administrative control panel said that there was a newer version I should upgrade.

So looking through files found in administrator/components/com_civicrm/civicrm.zip that might not have been expanded. Used comand line with ssh terminal to use unzip all. It inflated the archive. I then would receive and error in civicrm about rows not found thus CiviCRM would not launch. I just used the package installer to upgrade the files again.  I got a screen for files where successfully updated with a link to upgrade the database as before. But when I clicked the link to upgrade the database it then did the upgrade the database to 3.1.2 the installation. When I check through the functionality it appears to be successful.

This the status of my server.
Zip support is enabled in both PHP4 and PHP5 on the server. You can provide following output to vendor:

root@ariel [~]# php4 -i | grep -i zip
zip
Zip support => enabled

root@ariel [~]# php -i | grep -i zip
zip
Zip => enabled
Extension Version => $Id: php_zip.c,v 1.1.2.38 2007/08/06 22:02:32 bjori Exp $
Zip version => 2.0.0
Libzip version => 0.7.1

Related to expanding zip files. I was wondering how I might need to have the server configured differently so a package upgrade could work with out the additional manual expansion of the administrator/components/com_civicrm/civicrm.zip ?