4GL Access: RW1

The DataType attribute specifies the data type of the field's variable (if one exists).

When you create a field in Workbench, you specify the data type of the field in the Property Inspector. When you are creating fields dynamically, you must set this attribute yourself.

Depending on the type of field, the data type can be a simple data type, such as date or varchar(2000), or it can be a class name (either a user-defined user class, an external class, or one of the system classes). Usually for a scalar field it makes sense to use a simple data type, one compatible with the default data type of the actual field. A ToggleField, for example, is of limited use unless its data type is integer.

On the other hand, fields such as EntryField and the various ChoiceFields can work effectively with a range of data types. If a ChoiceField (an OptionField, for example) is set to integer, then when an entry is selected at runtime the corresponding EnumValue is applied as the chosen value. If instead the field is set to float, decimal, money, date, or varchar, the selected EnumText is coerced to the correct data type and applied as the chosen value. EntryFields work in a similar fashion, coercing the input value to the right data type.

For a composite field, the situation is more complex. Usually if a composite field is assigned a data type, it will be a system class or userclass type. In such cases, each child field that the composite contains will be processed at runtime depending on whether its name (and data type) matches one of the data type class's attributes. If it matches, the field uses that attribute for its value; if it does not match, the field behaves independently of the composite field when getting and setting its value.

The syntax for specifying the data type of a field using this attribute is exactly the same as the syntax for specifying the data type element in a variable declaration of a 4GL script, for example, integer, or varchar(256). System, external, or user classes can be specified as the simple class name, or as a fully qualified name, which includes the application name where the class or data type is defined. This can be useful where ambiguity is possible. OpenROAD checks the legality of the name when the frame is run.