Forums

Hi everybody,
Anyone ever experienced the need to save cf data with thousand of fields in database?
Any suggestion?
Is there a way from database? Like create a view from several tables and saving cf data in the view...

Any idea?

Hello enzo.orsi,
I'm not a Chrono professional, but after checking your new post, I think that the following links may help:
My form data isn't saving to the database correctly
My CFv5 form data isn't saving to the database correctly
How do I save form data to a database table?
How to load record data from a database table into your form
P.S: I'm just an automated service😉

Hi Enzo,

Personally I'd go back and re-design. Who is going to complete a form with thousands of fields?

You can do it with careful table design and possibly multiple DB Saves - the ChronoForms Admin forms can often get to have thousands of inputs.

Bob

It is more complicated...
I have 200 forms designed in cf.
At the end of each form, it is going to a common form containing PayPal payment and with database saving.
So this common form should save all the 200 form result somewhere...

I do not know if it clear...any idea?

Hi Enzo,

Save the common payment data into the PayPal table and give each record a unique id. Save the 200 forms to separate tables* and link to the PayPal table with the unique id.

Bob

* I imagine that these are probably groups of very similar forms tso you probably don't need 200 tables.

Hi Enzo,

Save the common payment data into the PayPal table and give each record a unique id. Save the 200 forms to separate tables* and link to the PayPal table with the unique id.

Bob

* I imagine that these are probably groups of very similar forms tso you probably don't need 200 tables.

Thank you Bob.
Unfortunately my architecture is so complicated...
With your solution, it means that in common form, I need to join 200 tables to get the right result...

I tried to change the format of fields in mysql table to text (instead of varchar(255)): it seems working...but I don't know for how many columns.
You do not like this solution, right?

Hi Enzo,

Only because it seems too complicated and therefore difficult to maintain and extend.

Making all the columns TEXT will slow the database down a bit as it has to allocate new space for each entry. Where you can you should use a smaller value of VARCHAR - 32 is usually enough for a name 64 for an email address . . .

If you have similar forms then it might be simpler in the long term to merge the tables - and or the forms. Hard to say more without knowing the what the forms are like.

Bob

Hi Enzo,

Only because it seems too complicated and therefore difficult to maintain and extend.

Making all the columns TEXT will slow the database down a bit as it has to allocate new space for each entry. Where you can you should use a smaller value of VARCHAR - 32 is usually enough for a name 64 for an email address . . .

If you have similar forms then it might be simpler in the long term to merge the tables - and or the forms. Hard to say more without knowing the what the forms are like.

Bob

Absolutely agree, unfortunately...

Bob,
I've got another idea!
Why have thousands of columns for 200 forms when all the columns have the same format (varchar)?
In the big table, I have already a column with the form_id...them I can have like 100 columns GENERIC with values for all the forms...

ID FORM_ID FIELD1 FIELD2
1 1 blablabla blablabla
2 1 blablabla blablabla
3 2 blablabla blablabla

Any contraindication?

Hi Enzo,

There is another method that I have used that might help you. You can take all the data from a form and json-encode it all into a single data item

<?php
$form->data['data'] = json_encode($form->data);
. . .

You can then have a data column in the table of type TEXT

You;ll also need a form_name column to identify which form each record is from

. . .
. . .
$form->data[' form_name'] = $form->form['Form']['title'];
?>

Bob

PS this is actually the way that ChronoForms saves all the data about a form in the Joomla! table (with some extra steps).

Thank you very much Bob.
It is a very good idea!

At the end I used a different solution, I changed the data model of the MySQL table.
Here attached the two different architecture.