Batch update via profile - working with few, not with many

[gsoundsgood]

I have a fresh CiviCRM install, version 4.2 on latest drupal.

Weirdly enough, I have batch update via profile working correctly if I select only a few contacts (apparently, up to about 15-20). If I select a few more, I get a blank screen (in firefox) or an HTTP Error 500 (in chrome).

I don't know if related, but when I created a new profile I got this error message:

Code: [Select]

Notice: Undefined index: note in CRM_UF_Form_Field->postProcess() (line 783 of /........./civicrm/sites/all/modules/civicrm/CRM/UF/Form/Field.php)
Batch update via profile has the same behaviour not only with my new profile, but also with the default ones.

On the same server, I have also a CiviCRM 4.1 installed on Wordpress working flawlessly.

Any suggestions?

[Kurund Jalmi]

Weirdly enough, I have batch update via profile working correctly if I select only a few contacts (apparently, up to about 15-20). If I select a few more, I get a blank screen (in firefox) or an HTTP Error 500 (in chrome).

Can you check your apache logs for errors. Also if possible enable display_errors = 1 in your php.ini, that will show errors on the screen instead of just blank screen

I don't know if related, but when I created a new profile I got this error message:

Code: [Select] [nofollow]
Notice: Undefined index: note in CRM_UF_Form_Field->postProcess() (line 783 of /........./civicrm/sites/all/modules/civicrm/CRM/UF/Form/Field.php)

This is just a notice and not related to above error.

HTh
Kurund

[gsoundsgood]

Hi Kurund!
thanks a lot, you pointed me in the right direction. I checked the error log, and I had:

Code: [Select]

PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted (tried to allocate 3370546 bytes) in .........public_html/civicrm/sites/default/files/civicrm/templates_c/en_US/%%06/069/0693F89E%%drupal.tpl.php on line 86
I wanted to batch update 50 records.

so I increased memory_limit in my php.ini file from 128MB to 256 MB, and I got:

Code: [Select]

PHP Fatal error:  Allowed memory size of 268435456 bytes exhausted (tried to allocate 8412688 bytes) in ...........public_html/civicrm/sites/default/files/civicrm/templates_c/en_US/%%06/069/0693F89E%%drupal.tpl.php on line 86
I increased it to 512MB and it did work, but it seemed to be amazingly slow.

I increased it to 1024MB, and it worked... still sluggish, but reasonable.

So basically, my issue is now solved. Thanks a lot.

Still, It's strange to see such a large amount of memory needed.

I have also to notice the fact that with the other CiviCRM I have installed on the same server, version 4.1 on top of Worpdress, I'm fine with memory_limit = 128 MB, and it goes much quicker.

So I wonder if I have some other setting out of tune, or if it is an issue of CiviCRM 4.2.

Thanks a lot!

[gsoundsgood]

After all the changes, when the contacts were finally listed, it was amazingly slow to modify anything in the batch update. I mean, the browser was actually very slow in responding.

I just had to remove from the fields of the profile "state" (I mean, the one for provinces/regions in Europe), and now everything is working fine. Speedy load of the batch, and quick to edit.

it seems that the real culprit was the "state" field. Fortunately for me, I don't really need it, I'll just leave it out.

thanks,

g.

[Kurund Jalmi]

I increased it to 1024MB, and it worked... still sluggish, but reasonable.

yes this is too high

I have also to notice the fact that with the other CiviCRM I have installed on the same server, version 4.1 on top of Worpdress, I'm fine with memory_limit = 128 MB, and it goes much quicker.

This is more appropriate setting.

it seems that the real culprit was the "state" field. Fortunately for me, I don't really need it, I'll just leave it out.

Thanks for reporting this we will investigate on this issue.

Kurund

[davej]

Hi Kurund,

it seems that the real culprit was the "state" field. Fortunately for me, I don't really need it, I'll just leave it out.

Thanks for reporting this we will investigate on this issue.

Was anything done on this? Seeing this issue on a 4.4.6 site.

Cheers,

Dave J