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:
Key field is any field for which the Key_Field_State property is set to true (your primary key).
Indexed field is any field that is not a key field and provides a segment in one or more of the table’s indexes.
Default field is any field that is not a key field or an indexed field.
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.