Author Topic: "one of the param.'s not of the type integer" when upgrading existing DB (Read 6146 times)

phani · January 16, 2009, 08:58:36 am

first i installed a fresh version of 2.2 onto a new drupal site (6.9) and everything seems to work fine (didn't try out the CiviMail features yet...). upgrading an existing CiviCRM installation (2.1) though, i ran into problems. the upgrade script didn't throw any errors, but when i try to open any of the existing records, i get this:

Code: [Select]

One of parameters (value: ) is not of the type Integerbacktrace:

Code: [Select]

/home/phani/public_html/nh/db/sites/all/modules/civicrm/CRM/Core/Error.php, backtrace, 260
/home/phani/public_html/nh/db/sites/all/modules/civicrm/CRM/Utils/Type.php, fatal, 254
/home/phani/public_html/nh/db/sites/all/modules/civicrm/CRM/Core/DAO.php, validate, 906
/home/phani/public_html/nh/db/sites/all/modules/civicrm/CRM/Core/DAO.php, composeQuery, 859
/home/phani/public_html/nh/db/sites/all/modules/civicrm/CRM/Core/BAO/CustomGroup.php, executeQuery, 1531
/home/phani/public_html/nh/db/sites/all/modules/civicrm/CRM/Core/BAO/CustomGroup.php, formatCustomValues, 1409
/home/phani/public_html/nh/db/sites/all/modules/civicrm/CRM/Contact/Page/View/Tabbed.php, buildCustomDataView, 60
/home/phani/public_html/nh/db/sites/all/modules/civicrm/CRM/Contact/Page/View/Tabbed.php, preProcess, 79
/home/phani/public_html/nh/db/sites/all/modules/civicrm/CRM/Core/Invoke.php, run, 197
/home/phani/public_html/nh/db/sites/all/modules/civicrm/drupal/civicrm.module, invoke, 318
, civicrm_invoke, 
/home/phani/public_html/nh/db/includes/menu.inc, call_user_func_array, 348
/home/phani/public_html/nh/db/index.php, menu_execute_active_handler, 18

some 'value' in the database, apparently related to custom groups, isn't what it's supposed to be (an integer), and CiviCRM complains about that.
i keep looking for the offending value, but perhaps somebody here knows already what i should look for?

phani.

Dave Greenberg · January 16, 2009, 12:02:59 pm

It looks like one of your custom fields is missing an expected value in the civicrm_custom_field.option_group_id column (used to link custom fields to option values - e.g. checkbox items, select values ...). Since this is not a new column in custom_field table - not sure how or why this would have gotten messed up in the upgrade.

Best would be to zip up a dump of your 2.1 DB and send it to Deepak to review / try the upgrade. We'll delete it when done.

deepak at webaccess dot co dot in

phani · January 16, 2009, 11:42:19 pm

thank you, that would be my last resort. for now, i'll try to figure out where the non-int that's not supposed to be there comes in. "value" in the option_values table is var_char, and even in a clean 2.2 installation a few values can't be read as integers ('daily', 'weekly', etc.), and that doesn't create problems. far as i can see, there aren't any values missing either.

the data i'm dealing with doesn't 'belong' to me; before sending them somewhere else i'd have to get permission. and while i don't have any doubt in the integrity of the person you mention, accidents do happen, and once i email the whole thing it's out of my hands...

phani.

phani · January 17, 2009, 06:49:41 am

spent all day trying to figure out what goes wrong where, but to no avail. in the process i noticed that my custom-group and -field structure is unnecessarily complex, and has a few logical errors. not errors in the DB structure, but multiple select fields where select would be needed, and too many custom options that could be left as plain text fields, since contacts won't need to be searched or grouped on them.

i remember that i had some trouble upgrading from 1.9 (i think) already, but got it straightened out eventually. simplifying the whole DB will make life easier in the long run, even if it's a bit of trouble right now: export everything as CSV, change data in spreadsheets, then import into a fresh CiviCRM installation with simplified custom structure.

still, the upgrade script returns with no errors, when obviously some errors are there. if you think it's useful for you to figure out what went wrong, i can send the mysqldump to deepak; convinced myself that i'm being overly paranoid, that people you recommend for this type of work won't be as careless as some western spy agencies apparently are, leaving CD's or whole laptops in metro trains, etc.

phani.

Donald Lobo · January 17, 2009, 07:02:38 am

1. i assume you have a working 2.1 install

2. the upgrade to 2.2 breaks all contact view?

if so, please send in the working 2.1 DB to deepak.

lobo

phani · January 17, 2009, 07:36:00 am

my 2.1 install works fine. not all contact views break, only individuals with custom values. households also have custom fields, but they don't break. individuals have far more, and one or the other of them must cause the trouble. individuals with no custom data filled in display fine.

i'm sending the dump to deepak now.

phani.

Deepak Srivastava · January 19, 2009, 04:12:05 am

The error was due to a bug in 2.2 codebase, and has been fixed - http://fisheye.civicrm.org/browse/CiviCRM/branches/v2.2/CRM/Core/BAO/CustomGroup.php?r1=19303&r2=19416

phani, thanks for your db. It really helped tracing the problem.
Patch is simple. You could apply and check if everything else looks on track.

phani · January 19, 2009, 06:12:23 am

great, thank you very much. appears to be a silly little mistake in the code, but i would never have guessed where to look for it.

after importing the DB again, contacts display fine, but at least one of the custom groups, "spiritual information" in my DB, seems to have lost the info that was stored in the original DB. (select, 2 x multiple-select, and a text-area). i could live with that, but you might want to find out why they disappeared...

phani.

phani · January 19, 2009, 06:57:28 am

actually, the info. is still there in the DB, but for some reason it doesn't get displayed.

phani.

update: when editing a contact, the info is diplayed ok, but in the summary view, it's not.

Deepak Srivastava · January 20, 2009, 11:49:14 pm

Phani, we were able to replicate and fix the problem - http://fisheye.civicrm.org/browse/CiviCRM/branches/v2.2/CRM/Core/BAO/CustomGroup.php?r1=19416&r2=19451

You should now be able to see all your data (unless we missed anything).

If you find it difficult to apply the patch, you can replace the file - CRM/Core/BAO/CustomGroup.php, with the latest file from the svn - http://svn.civicrm.org/civicrm/branches/v2.2/CRM/Core/BAO/CustomGroup.php

And let us know if you still notice any problem.

thanks,
Deepak

phani · January 21, 2009, 02:05:03 am

this looks fine now; haven't noticed any further problems and will let you know if i do.

thanks, phani.

CiviCRM Community Forums (archive)

News:

Author Topic: "one of the param.'s not of the type integer" when upgrading existing DB (Read 6146 times)

phani

"one of the param.'s not of the type integer" when upgrading existing DB

Dave Greenberg

Re: "one of the param.'s not of the type integer" when upgrading existing DB

phani

Re: "one of the param.'s not of the type integer" when upgrading existing DB

phani

Re: "one of the param.'s not of the type integer" when upgrading existing DB

Donald Lobo

Re: "one of the param.'s not of the type integer" when upgrading existing DB

phani

Re: "one of the param.'s not of the type integer" when upgrading existing DB

Deepak Srivastava

Re: "one of the param.'s not of the type integer" when upgrading existing DB

phani

Re: "one of the param.'s not of the type integer" when upgrading existing DB

phani

Re: "one of the param.'s not of the type integer" when upgrading existing DB

Deepak Srivastava

Re: "one of the param.'s not of the type integer" when upgrading existing DB

phani

Re: "one of the param.'s not of the type integer" when upgrading existing DB