After creating a composite table diagram and selecting simple tables and connecting them with relations, you must create composite table fields. Composite table fields define the structure of a composite table row. A composite table field is based either on a constituent simple table field, or on a calculated (unbound) field.

To define a composite table field based on a simple table field, use the Diagram tab of the Composite Table Editor. Every field of every simple table in the diagram has a check box. Check this check box to include it in the composite table field collection.

Checking the check box creates a CompositeTableField object referring to the simple table field via the TableViewField property. Primary key fields are always checked, they must be present in the composite table to form its primary key, so you cannot uncheck them. Child relation fields (fields that appear on the child side of a relation connecting simple tables) are always unchecked, they are not allowed to be included in the composite table because they have no independent meaning, and their values are always the same as the values of the corresponding parent keys.

The composite table field collection is shown in the Properties tab of the Composite Table Editor, in its bottom panel (its top panel shows the CompositeTable properties).

In addition to fields based on simple table fields, a composite table can contain unbound (calculated) fields. A composite table field is unbound if its TableViewField property value is empty. Unbound fields are usually calculated either by Calculations (expressions) or in code. Unbound field values are stored in composite table rows, see Structured Data Storage: Tables and Table Views. To create an unbound field, click the Add button or select Add from the context menu in the Fields list.

A composite table field has a name that must be unique in the composite table. It has the same function as the name of a simple table field; for more information, see Table Fields. A field can be renamed by renaming the field node in the Fields list. Using this list and its button bar, you can add, delete and reorder composite table fields.

CompositeTableField properties are the same as the properties of a simple table field, although some properties are not applicable in composite table, and thus are hidden. For an unbound (calculated) composite table field, its properties have exactly the same meaning as simple table field properties, see Table Fields. For a bound composite table field (one based on a simple table field), its properties have some special inheritance-like features:

• Some properties inherit their value from the corresponding property of the simple table field (determined by the value of the TableViewField property) and that value cannot be changed unless it is changed in the original simple table field. Such properties are: DataType, NativeDbType, AutoIncrement, AutoIncrementSeed, AutoIncrementStep, DefaultValue, MaxLength, Precision, Scale, and Unique.
• Some properties can be changed, but their effective value at run time is determined by the conjunction of their value and the value of the property of the base simple table field. Such properties are: ReadOnly, ReadOnlyUnlessNew, and AllowDbNull.
• The remaining properties can be specified in a composite table field independently of their value in the base simple table field. Such properties are: CalculationCondition, CalculationExpression, Calculations, and Constraints.

Every modifiable table in DataObjects for .NET must have a primary key, and composite tables are no exception. A composite table's PrimaryKey is composed of bound composite table fields that belong to the primary key of their simple table (have PrimaryKey = True), except child relation keys (fields that appear on the child side of a relation connecting simple tables). This is the rule determining the value of the PrimaryKey property of a composite table field and the value of CompositeTable.PrimaryKey.