Error 0 Element params too big to save, probably calculation data, for element ID 4

[doitsolutions.com.au]

Hello,

I love Fabrik. However I have a database table in one single list with over 350,000 lines and 9 columns.
I have set the list to not show data until filters have been applied, and I have created a search form.

However, on occasion (more often than not) the page goes down with this error:
Element params too big to save, probably calculation data, for element ID 4

Element ID 4 is an "Amount" column. This amount is totalled for each grouping. (The list is grouped by address and ordered by name, the "amount" for each group is totalled.

Is it simply having to store too many totals?
Is there a way around this? I can throw as much RAM and CPU as I need at this, I just need it to work, and I will be increasing the database lines to over 500,000 soon.

I have the site loaded here:
http://served.net.au/unclaimedmoneyregistry.com.au/
After searching for something a little too ambiguous, it craps itself with the above error.

I am using Fabrik 3.6 on Joomla 3.7.0

Thank you,
Michael A.

 

[doitsolutions.com.au]

Here is the "params" value for Element ID 4:

{"placeholder":"","password":"0","maxlength":"12","disable":"0","readonly":"0","autocomplete":"1","speech":"0","advanced_behavior":"0","bootstrap_class":"input-medium","text_format":"decimal","integer_length":"6","decimal_length":"2","field_use_number_format":"1","field_thousand_sep":",","field_decimal_sep":".","text_format_string":"","field_format_string_blank":"1","text_input_mask":"","text_input_mask_autoclear":"0","text_input_mask_definitions":"","render_as_qrcode":"0","guess_linktype":"0","link_target_options":"default","rel":"","link_title":"","show_in_rss_feed":"0","show_label_in_rss_feed":"0","use_as_rss_enclosure":"0","rollover":"","tipseval":"0","tiplocation":"top-left","labelindetails":"0","labelinlist":"0","comment":"","edit_access":"1","edit_access_user":"","view_access":"1","view_access_user":"","list_view_access":"1","encrypt":"0","store_in_db":"1","can_order":"0","alt_list_heading":"","custom_link":"","custom_link_target":"","custom_link_indetails":"1","use_as_row_class":"0","include_in_list_query":"1","always_render":"0","icon_folder":"0","icon_hovertext":"1","icon_file":"","icon_subdir":"","filter_length":"20","filter_access":"1","full_words_only":"0","filter_required":"0","filter_build_method":"0","filter_groupby":"text","inc_in_adv_search":"1","filter_class":"input-medium","filter_responsive_class":"","tablecss_header_class":"","tablecss_header":"","tablecss_cell_class":"","tablecss_cell":"","sum_on":"1","sum_label":"Total","sum_access":"5","sum_split":"","avg_on":"0","avg_label":"Average","avg_access":"5","avg_round":"0","avg_split":"","median_on":"0","median_label":"Median","median_access":"5","median_split":"","count_on":"0","count_label":"Count","count_condition":"","count_access":"5","count_split":"","custom_calc_on":"0","custom_calc_label":"Custom","custom_calc_query":"","custom_calc_access":"1","custom_calc_split":"","custom_calc_php":"","validations":[],"join_val_column_concat":null,"sum_value_serialized":"a:1:{s:5:\"Total\";O:8:\"stdClass\":6:{s:5:\"value\";s:4:\"0.00\";s:5:\"label\";s:5:\"Total\";s:5:\"class\";s:10:\"splittotal\";s:7:\"special\";b:1;s:7:\"elLabel\";s:12:\"Amount Total\";s:8:\"calLabel\";s:5:\"Total\";}}","sum_value":"<dl>\n<dt><span class=\"calclabel\">Total<\/span><\/dt>\n<dd class=\"splittotal\"><span class=\"calclabel\">Total:<\/span> 0.00<\/dd>\n<\/dl>"}

Any ideas?

 

[doitsolutions.com.au]

This is weird, check out the total "amount" about halfway down on this query:
http://served.net.au/unclaimedmoney...First_Name=John&___Last_Name=Smith&isMambot=1

It is not reouping the results properly, could this be the cause? It seems to be bunching a mess of data into the total column instead of adding rows when multiple matches exist.

 

[cheesegrits]

OK, this issue will be fixed in 3.6.1, when we increase the 'params' field in the #__fabrik_elements table to MEDIUMTEXT as part of the update, and remove that exception handling.

Meanwhile, if you update to the latest github, so you get the commit just I just made:

https://github.com/Fabrik/fabrik/commit/a7e080065072c42cb7d126f1b795b5f815709e79

... we should automatically increase that params field from TEXT (64k) to MEDIUMTEXT (16m) if you are trying to store params >64k in size, rather than throw that exception (which was a temporary measure to prevent the backend getting totally broken, which is what happens if you store a JSON string that gets truncated).

-- hugh

 

[doitsolutions.com.au]

I have limited experience with github updates, I will attempt to only update the element.php file you linked me to. I am reluctant to upload all of the other files unless it is imperative to do so.

I will let you know how I go. I thought it was the field setting in the database but that is already set to mediumtext for the params field in the elements table.

I will update you soon.

 

[doitsolutions.com.au]

I have read your guide on updating from Github and updated all files the proper way.
So far so good on the error message front. Thank you for your help. This is great!

I thought that the other symptom I lynked would have been related, but it is still occuring.
Please check out these results when I search for "John Smith":
http://served.net.au/unclaimedmoney...First_Name=John&___Last_Name=Smith&isMambot=1

About halfway down, instead of a total amount it shows a mass of data, I am not sure what that is coming from, does this look like a familiar problem?

 

[doitsolutions.com.au]

All good, I believe it was a problem with my data (very long addresses with possible illegal characters). Thanks for your help, all working well now.