Defining Data Dictionary Foreign Fields Attributes

Within your data entry object the Entry_Item command binds a table and table-field value to a form or to a column within a grid. This table will either be the main file of the DEO’s Data Dictionary, or it will be a parent table. When used as a parent table, the Entry_Item is considered to be a connected to a "foreign field." It is important to understand the concept of a foreign field. The following example shows an entry-item that is not foreign followed by an entry-item that is foreign:

// part of an order entry view


Object oOrderNumber is a dbForm

    Set Server to oOrderhea_DD

    Entry_Item Orderhea.Order_number // this is not a foreign field



Object oCustomerName is a dbForm

    Set Server to oOrderhea_DD

    Entry_Item Customer.Name // this is a foreign field


An example of a foreign field is the Customer.Name field when it appears in an Order Entry view. This is because it is the Order Header table that provides the server Data Dictionary; the Customer table in this example is a parent of the order header.

// part of a customer maintenance view


Object oCustomerName is a dbForm

    set Server to oCustomer_DD

    Entry_Item Customer.Name // this is not a foreign field


When the Customer.Name field appears in a Customer Maintenance view, it is not a foreign field because in this case the Customer table provides the server Data Dictionary.

When the Entry_Item  file-number is not the same as the number of the Data Dictionary’s main file, the file should be an ancestor (parent, grandparent, etc.) table. If it is not, you have probably made an error.

Ancestor-file entry items are usually used differently from main-file entry items. When entering a new record for the main file, the parent-file records are not modified. Their role is to provide field values (customer number, etc.) on which relations are based from the main file to the parent. When the parent table must be changed (add, delete, modify) this is done in a different view, in which that table is the DDO’s main file.

Because of this, foreign fields often require additional field option settings. Although foreign-field options may be assigned to individual fields, this is little need to do this, as there is a more-convenient way to set these foreign field options. Foreign fields can be divided into three categories. Those are:


By defining foreign field options for each of these categories of fields (DD_KEYFIELD, DD_INDEXFIELD, DD_DEFAULT) your data entry applications provide the right kind entry situations with no extra programming.

Foreign-field properties are added to any regular field option properties.  The following example shows a very typical use of foreign field options.

Set Field_Option field Customer.Id DD_NoPut to True

Set Field_Option field Customer.Id DD_AutoFind to True

Set Field_Option field Customer.State DD_CapsLock to True

Set Field_Option field Customer.Balance_Due DD_DisplayOnly to True


// Define default foreign field options

Set Foreign_Field_Option DD_KEYFIELD DD_FindReq to True

Set Foreign_Field_Option DD_INDEXFIELD DD_NoPut to True

Set Foreign_Field_Option DD_DEFAULT DD_DisplayOnly to True

In this example, the regular (non-foreign field) field options for Customer.Id will be No-Put, Auto-Find and Capslock. Its foreign-field options will be No-Put, Auto-Find, Capslock and, since it is a key field, Find-Required.

All regular field-options may be set as foreign-field options. In practice the only options you are likely to set are DD_NoPut, DD_NoEnter, DD_DisplayOnly, DD_AutoFind and DD_FindReq.