Required Field

Overview

Required fields on the Form Designer

A netFORUM Column can be configured to be required. Any non-NULLable columns must, by necessity, be required. If a Column is required, then when this is placed on a Form using the Form Designer, then the form control will be required as well.

As straightforward as this seems, there can be some scenarios that complicate required fields.

Sometimes, when trying to submit a form, additional fields are required other than those which are labeled as such (typically in bold). This article describes the different kinds of required fields and how to identify them.

Kinds of Required Fields

Below are the different variants of required fields and how to identify them.

Normal Required Fields

By default, required fields are denoted as such by having bold field labels. Technically, this is done by setting the control style to the DataFormLabelRequired CSS class. If the user does not enter a value in this field, then at submission time the user will receive an error message stating: 

SomeField is required.

Where "SomeField" is the name of the required field.

Unbolded Required Fields

Unbolded required fields are like Normal required fields, but do not have bold labels. These types of fields might be considered bugs in the software and should be treated as such.

For example, consider the "Add Address" form. The "State" field is a Hidden required field only if the country is United States. Not all nations have the concept of a "state/province", so this field cannot be universally required. Its label is not bold, but if you fail to specify a State when the address is in United States, then you'll get an error message on submission which reads "state is required".

It is a design limitation in netFORUM that this field's label cannot be conditionally highlighted in bold. The netFORUM Form Designer is not able to conditionally change the control style CSS class of a control; this could cause design/layout problems because as the system changes, the entire form layout could change as controls expand and contract. This is not an easy issue to resolve. As such, these types of variable required fields are typically shown not-bolded. Out of more than 50,000 form controls in all of netFORUM, there are believed to be several dozen controls like this.

Obscure Required Fields

These required fields are much more difficult to identify and troubleshoot. Their labels might not be marked in bold, just like Unbolded required fields, but instead of getting an error reading "SomeField is required", you get this: 

The statement has been terminated. Additional fields are required.

There is no universal or easy way to determine which field causes this error to occur for any given form.

Troubleshooting

In the event you run into an obscure required field, here are the steps to troubleshoot.

Error 

The statement has been terminated. Additional fields are required.

Investiation

When you hear such a report from an end user, then an administrator can go to the Admin module and navigate to Error Log. List error logs will give you a list from that table. I do not think that will help the end user, but it is better than having to have SQL Tools and access to the database. [todo]:

Explanation

Technically, this message comes from the Error Message table. It is triggered by an error from SQL Server that can be either of two errors:

  • A non-nullable column is not given a value for an insert (typically) or an update (more rarely).
  • A foreign key constraint is violated. For example, a value is inserted into a column that contains a foreign key (such as cph_pht_key which is the column in the co_customer_x_phone table that stores the value of a phone type from co_phone_type.pht_key). This can happen if a certain System Option default value contains an invalid key or code, and that key or code is being inserted into a certain foreign key column, thereby causing the SQL foreign key constraint error.

Resolution

If the problem is caused by an improperly specified System Option, this is mostly ikely to surface early in testing/implementation of a module. This points to a setup issue and not necessarily a "programming" issue. Resolution:

  1. Look for the error in the fw_error_log table. This could happen early in an implementation if certain key setup values are overlooked.
  2. In the err_sql column you will see the see SQL command that caused the error.
  3. Manually execute this command in an SQL Query and see the error; you will be able to determine the invalid value.
  4. Find the System Option with the invalid value by searching for any system option(s) that have that value.
  5. Replace the incorrect system option value with a valid value.

Or, you might have a form that does not prompt for an entry into a database column that is non-nullable. This issue is most likely caused by a Catch-22 situation with a form in alpha or beta mode that still needs work. Or you might have a form that will not work under certain scenarios. This is most likely caused by a snag in how the form or its underlying tables and relationships are created, or maybe the form just needs more design fine-tuning. If you believe you see this occuring on a baseline form, then before you start trying to "fix" the form, please do more troubleshooting or check with Avectra. Again, this situation is usually diagnosed and solved early in testing and should generally not appear in baseline.

To solve this problem:

  1. Ensure that the Form has all required field inputs, or
  2. Make sure if you have non-required form controls for non-nullable columns, you made those controls be required on the Form.
  3. Check to see if you have a malfunctioning Related Object or Lookup that is not properly setting required/non-null fields.