Forums

I had a form that has been working for some time. Yesterday, I upgraded to the latest version of CF (as well as the latest CC). Now, the form does not work correctly.

The form was using a DB Record Loader to bring in data under the model id 'ConfirmReg'. The form would save the data into a new table. In the past, I used sytax like '{ConfirmReg.<field>}' in the Field Default Value in order to display data from the Record Loader. Now, however, that will not work, and all I get is that syntax in the form field. The only thing I can see to do is to use PHP in a custom code action to populate the fields. Seems weird that it was working fine until this update.

Thanks!
Rick

In addition, the form was saving a value back to the original table (indicating that the record had been confirmed). This no longer works after the update(s).

Hi Rick,

I have removed a setting in the DBRL which populates fields values and replaces the curly strings, this has been left for the Show HTML only, so please make sure that you have the Show HTML configured to do the curly replacements.

You may also set the field value using php in custom code so the show html may populate it:

<?php
$form->data['field'] = $form->data['ConfirmReg']['field'];
?>

OR change the field name and it will be auto republished, change from: name="field" to name="ConfirmReg[field]"

Regards,
Max

Got it. No problem! I already used the PHP (like you mention) to write the values, so I am good to go.

My second issue, where a field is not written back to the original table, still exists. It was not using curly brackets.

Any ideas on this?

Hi Rick,

My second issue, where a field is not written back to the original table, still exists. It was not using curly brackets.

What's the field name and type ? is this in CC ? if so then your field name should match the model Id if you have one setup.

Regards,
Max

It is not in CC, but in CF. In the form, I had a field named 'co_authorized'. It was a hidden field on the form, used to set the value of this field to 'Y' when the form was submitted. Until the latest update it was working fine. The form uses a DB Record Loader action in the On Load event to open a record from a table named 'inejf_chronoforms_data_registration'. The form user can make changes to the displayed fields. In the On Sumbit event, the form values are written to a new table, 'inejf_customer_info' using a DB Save Action. In addition, the form was running another DB Save that was setting the value of 'co_authorized' to 'Y' in the original table. That's what is not working now.

The original DB Record Load was done under the model ID 'ConfirmReg', but I did not have to use this before in order for the value of 'co_authorized' to be set. Do I need to do that now? If so, would the field name be '[ConfirmReg][co_authorized]'?

I have tried the following, to no avail:

1) Set the hidden field name to '[ConfirmReg][co_authorized]'
2) Set the DB Save action to save under the model ID (it was not set to this before), and set the model ID to 'SaveRecordBack'. Then, I set the hidden field name to '[SaveRecordBack][co_authorized]'

Also tried setting the field name to 'ConfirmReg[co_authorized]' and 'SaveRecordBack[co_authorized]'. Neither worked.

I am more than willing to pay to get this fixed. My client is irate with me!! 😶

Ok, as usual, I am the moron!!!

The form also had a hidden field that was pulling in the original table's ID (cf_id) in order to be able to save the 'co_authorized' field back. Well, it was using the curly brackets in the default value. Since I had previously used the PHP method for populating the form field and had not turned on the curly replacer in ShowHTML, it was not populating this field. Once I added the PHP line to do so, it worked perfectly.

Sorry for the inconvenience!!!

😶 😶 😶 😶

Hi Rick,

Well, apologizes for not responding, I had some late stuff the last couple of days and completely missed this topic!😟

If you have it working then good, but you shouldn't be loading data from other resources in the connection edit page, because this data mix may cause overwrites, I believe that fixing the field name would have been enough, a column named X under a table with MODEL_ID = Y should be loaded under a field name = Y[X]

examples:

User[username]
Profile[signature]
Article[title]

Regards,
Max

Well that's probably where I went wrong. I was using "Y[X]" in the "Default value" field, not in the field name.