Relates-to Constraints

Set Constrain_File To Customer.File_Number

A relates-to constraint is used when you want to only display records in a table that are children of the record in a related-to parent DDO. The classic example of a relates-to constraint is found in an Order Entry System where a grid of order-detail records is only displays records belonging to an order-header record.

Relates-to constraints are defined by setting the Constrain_File property in a child Data Dictionary object. This is usually done statically at the DD object level. The following example would constrain all Order records to a customer record

Object oCustomer_DD Is A Customer_DataDictionary

End_Object    // oCustomer_DD

 

Object oOrderHea_DD Is A OrderHea_DataDictionary

    Set DDO_Server To oCustomer_DD

    Set Constrain_File To Customer.File_Number

End_Object    // oOrderHea_DD

Data Dictionaries handle relates-to constraints in a very special way. The propagation rules for finds and clears are different when a relates-to constraint is in effect. This is discussed in detail in DDO Propagation and Relate-to Constraints.

A number of requirements must be met for a relates-to constraint to operate properly:

  1. A relationship must be defined between the child and parent table. This relationship must be defined inside of the Studio’s Data Dictionary Modeler. This requires that the child table define the field or fields that relate to a corresponding set of fields in the parent.

  2. The value of the related-to field (or fields) in the parent must be unique and supported by an index whose segment (or segments) are the same as the related to field.

  3. The child table should contain one or more indexes that allow for fast finding by the relating fields. This means that the first segments in this child should consist of the relating-to fields.

  4. The Child DDO must be properly connected to the Parent DDO, by setting the DDO_Server property in the child.

 

Rules 1 and 2 are the standard rules used to define any parent-child relationship and is required for the relate and attach processes to work properly. Rule 3 makes it possible for DDOs to quickly find related records. It allows the DDOs to jump into an index to find the first (or last) related record and to jump out of the index when the last (or first) related record is found. While you can find related child records using other non-optimized indexes the performance with large tables will almost always be unsatisfactory.

In our above example, this would require that:

 

Object oCustomer_DD Is A Customer_DataDictionary

End_Object    // oCustomer_DD

 

Object oOrderHea_DD Is A OrderHea_DataDictionary

    Set DDO_Server To oCustomer_DD

    Set Constrain_File To Customer.File_Number

End_Object    // oOrderHea_DD

Relates-to Constraints may be applied at multiple levels. In the following example, Orders are constrained to Customers and Order-Detail items are constrained to Orders.

Object oCustomer_DD Is A Customer_DataDictionary

End_Object    // oCustomer_DD

 

Object oOrderHea_DD Is A OrderHea_DataDictionary

    Set DDO_Server To oCustomer_DD

    Set Constrain_File To Customer.File_Number

End_Object    // oOrderHea_DD

 

Object oOrderDtl_DD Is A OrderDtl_DataDictionary

    Set DDO_Server To oOrderHea_DD

    Set Constrain_File To OrderHea.File_Number

End_Object    // oOrderDtl_DD

These types of constraints are most often used in top down data-entry and reporting. For example, you would first find a customer, then find an order that is the child of the customer, and then find an order detail that is a child of the order-detail.

Data Dictionaries support an auto-fill capability that can be used in conjunction with relates to constraints. A find in a related-to parent Data Dictionary always notify the related child Data Dictionary of this change. Since the child DDO must contain a valid constrained record it will either clear itself or, if Auto_Fill_State is true, find the first valid record.  This auto-fill behavior is used to display detail grids in a data entry application.

It is a good rule to use only as many relates-to-constraints required to do the job.  This kind of constraint is not needed to make saves and deletes work properly – it is only used to find records.

See Also

Constraints and Filters