Author Topic: Upgrade from 3.4.5 to 4.1.1 failed - $onbehalfProfileId missing (is it needed?) (Read 842 times)

mcgeehon · June 26, 2012, 05:19:05 pm

I am trying to upgrade an existing civicrm database from 3.4.5 to 4.1.1. I only get as far as pushing the upgrade button, followed by a few seconds and then the error message.

I have tried the steps detailed in another post to disable CiviCRM module in Drupal, remove the civicrm.settings.php file, install civirm, remove the database, restore the original database and try again. No luck.

Any suggestions are welcome. The backtrace is attached.

jmickela · June 26, 2012, 07:34:32 pm

Odd, I'm having the exact same problem on my server...

Especially odd since I'm doing this upgrade a second time, the only difference being a newer data set, and it went fine the first time, and is totally bombing now. I'm starting to think there's something wrong with the data itself.

Are there any tables that, if not deleted/removed, will cause the installer to error out? Like, temporary import tables?

Hershel · June 27, 2012, 06:19:00 am

mcgeehon,

I see this:

Code: [Select]

Jun 26 17:05:26 [info] Ignoring exception thrown by nullHandler: -18, DB Error: no such table
in your backtrace. Not sure what table it is, however. May be coming from the retrieveDirectoryAndURLPreferences function, but I'm not sure.

mcgeehon · June 27, 2012, 07:55:28 am

Thanks. Is there a way to trace CiviCRM in a way to identify which DB/table/function it is having the issue with? Or turn on CiviCRM backtrace in a way that it identifies the table in question?

My initial thought was that the DB schema was modified in someway by my predecessor, and that this might be causing the problem, though I am not sure.

Donald Lobo · June 27, 2012, 08:57:45 am

check the CiviCRM.MD5 HASH.log file in: files/civicrm/ConfigAndLog directory

should have the offending query

lobo

mcgeehon · June 27, 2012, 11:31:24 am

Lobo,

That is the file that I took the backtrace from. Unfortunately, there isn't much else in that file other than what I originally attached.

Basically, all I see is something like:

Code: [Select]

Donald Lobo · June 27, 2012, 12:11:59 pm

sorry, dont know.

Seems like it has something to do with the settings table etc. Might want to ensure you are using a clean working 3.4.5 db. Can you check if there is a civicrm_setting table in your db?

lobo

mcgeehon · June 27, 2012, 12:18:16 pm

So, there isn't a civicrm_settings table in my current 3.4.5 DB. I wasn't sure if this is expected in the 3.4.5 schema, or if my predecessor took it out?

I most likely will have to do a clean install and compare the two databases.

Donald Lobo · June 27, 2012, 12:51:58 pm

the setting table was introduced in 4.1. so not having it is correct in 3.4

lobo

jmickela · June 27, 2012, 02:26:24 pm

I've tracked the problem down to these lines of code:

Code: [Select]

$onBehalfProfileId = CRM_Core_DAO::getFieldValue( 'CRM_Core_DAO_UFGroup', 'on_behalf_organization', 'id', 'name' );
        if ( ! $onBehalfProfileId ) {
            CRM_Core_Error::fatal( );
        }

This looks in the civicrm_uf_group table for a record that has the value 'on_behalf_organization' in the name column and errors out if one isn't found. Looking at my data, I do not have this value in that table. Can I insert it somehow? What should it be? Why isn't it there?!?

Edit:
I commented out the CRM_Core_Error::fatal( ); and the upgrade went off without a hitch. the value of $onbehalfProfileId is used in:

Code: [Select]

while( $pages->fetch( ) ) {
            $query = "
INSERT INTO civicrm_uf_join
    (is_active, module, entity_table, entity_id, weight, uf_group_id)
VALUES
    (1, 'OnBehalf', 'civicrm_contribution_page', %1, 1, %2)";

            $params = array( 1 => array( $pages->id, 'Integer'),
                             2 => array( $onBehalfProfileId, 'Integer') );
            CRM_Core_DAO::executeQuery( $query, $params );
        }

But on my system $pages->fetch() contains no data to begin with, so regardless of the value of $onbehalfProfileId, it's never used.

My main concern is moving forward with this data. If $onbehalfProfileId is so important that the absence of a value bombs the entire upgrade, even if it isn't actually used, can I rely on my site without it? Or should it be used in all cases? I exceuted the SQL in:

Code: [Select]

$pages = CRM_Core_DAO::executeQuery("
SELECT    civicrm_contribution_page.id 
FROM      civicrm_contribution_page
LEFT JOIN civicrm_uf_join ON entity_table = 'civicrm_contribution_page' AND entity_id = civicrm_contribution_page.id AND module = 'OnBehalf' 
WHERE     is_for_organization = 1 
AND       civicrm_uf_join.id IS NULL
" );

And it came up with nothing. is that another potential problem? Should this SQL *always* return some rows?

CiviCRM Community Forums (archive)

News:

Author Topic: Upgrade from 3.4.5 to 4.1.1 failed - $onbehalfProfileId missing (is it needed?) (Read 842 times)

mcgeehon

Upgrade from 3.4.5 to 4.1.1 failed - $onbehalfProfileId missing (is it needed?)

jmickela

Re: Upgrade from 3.4.5 to 4.1.1 failed - unexpected unrecoverable error

Hershel

Re: Upgrade from 3.4.5 to 4.1.1 failed - unexpected unrecoverable error

mcgeehon

Re: Upgrade from 3.4.5 to 4.1.1 failed - unexpected unrecoverable error

Donald Lobo

Re: Upgrade from 3.4.5 to 4.1.1 failed - unexpected unrecoverable error

mcgeehon

Re: Upgrade from 3.4.5 to 4.1.1 failed - unexpected unrecoverable error

Donald Lobo

Re: Upgrade from 3.4.5 to 4.1.1 failed - unexpected unrecoverable error

mcgeehon

Re: Upgrade from 3.4.5 to 4.1.1 failed - unexpected unrecoverable error

Donald Lobo

Re: Upgrade from 3.4.5 to 4.1.1 failed - unexpected unrecoverable error

jmickela

Re: Upgrade from 3.4.5 to 4.1.1 failed - unexpected unrecoverable error