Database column fields

Form fields defined with a table and column name get data type from the database schema file.

Syntax 1: In grid-based container

item-type item-tag = [table.]column
    [ , attribute-list ]  ;

item-type [table.]column
    [ , attribute-list ]  ;

item-type references an item type like EDIT.
item-tag identifies the layout location of the field.
table is the name or alias of a table, synonym, or view, as declared in the TABLES section.
column is the name of a database column.
attribute-list is a list of field attributes.

Usage

A form field is typically based on the definition of a database column found in the database schema specified with the SCHEMA clause at the beginning of the form file. The database column defines the data type of the form field.

Important: The data type of a form field is only used by the CONSTRUCT interactive statement to do database queries. When using the form field with an INPUT, INPUT ARRAY or DISPLAY ARRAY dialog, the type of the program variable defines the data type of the form field.

In order to reference database columns, the table name must be listed in the TABLES section of the form.

Fields are associated with database columns only during the compilation of the form specification file: The form compiler examines the database schema file to identify the data type of the column, and defines the form field with this type. This technique allows to centralize form field data types in the schema files: If the data type of a column changes, extract the schema again and recompile your forms to take the new type into account.

Note: The compilers do also grab other field attributes like validation rules and video display attributes from .val and .att schema files. However, this is supported for backward compatibility only (formerly stored in syscolval and syscolatt database tables). Consider reviewing programs using this feature.

After the form compiler identifies data types from the schema file, the association between fields and database columns is broken, and the form cannot distinguish the name or synonym of a table or view from the name of a screen record.

The programs only have access to screen record fields, in order to display or input data using program variables. Regardless of how you define them, there is no implicit relationship between the values of program variables, form fields, and database columns. Even, for example, if you declare a variable lname LIKE customer.lname, the changes that you make to the variable do not imply any change in the column value. Functional relationships among these entities must be specified in the program code, through screen interaction statements, and through SQL statements. It is up to the programmer to determine what data a form displays and what to do with data values that the user enters into the fields of a form. You must indicate the binding explicitly in any statement that connects variables to forms or to database columns.

If a form field is declared with a table column using the SERIAL, SERIAL8 or BIGSERIAL SQL type, the field will automatically get the NOENTRY attribute, except if the field is defined with the TYPE LIKE syntax.

Example

Grid-based container database form field definition:

SCHEMA stores  -- Database schema
LAYOUT
GRID
{
 [f001             ]
 ...
}
END
END
TABLES
  customer  -- Database table
END
ATTRIBUTES
EDIT f001 = customer.fname,  -- DB-col form field
     REQUIRED, COMMENTS="Customer name";
...

Stack-based container database form field definition:

SCHEMA stores  -- Database schema
TABLES
  customer  -- Database table
END
LAYOUT
  STACK
  GROUP
    EDIT customer.fname, -- DB-col form field
         REQUIRED, COMMENTS="Customer name";
  ...