The technique by which the Relativity DBMS accomplishes this can be quite involved. It can be thought of as a process whereby the Relativity DBMS builds a record according to each record type and then tests the table filters and record type filters, until both of these filter expressions are true or until all of record types have been tried. In the latter case, the SQL INSERT statement will fail.
The Relativity DBMS may test both the value of a factor and set items to make the filter result true. To understand what the Relativity DBMS must do, it is necessary to review exactly what a filter expression is.
A filter expression consists of one or more factors connected with logical AND operators. Each factor consists of one or more filter subexpressions connected with logical OR operators. Each subexpression is either a condition-name or a logically complemented condition-name.
Therefore, for a filter expression to be true, each factor must be true. For a factor to be true, at least one of the subexpressions of the factor must be true. For a subexpression to be true, the condition-name must be either false or true, depending on whether it is complemented or not, respectively. A factor that consists of a single subexpression is a very special case since it requires that the condition-name in this subexpression be true or (if complemented) false. Thus, requiring that the filter expression be true may force particular values be stored in the data items on which such condition-names are defined. The Relativity DBMS may use that fact to determine the values of some items in the record.
The complemented condition-names in a filter are a problem. Some, but not all, condition-names define a "SET TO FALSE" value. To set these condition-names to false, the Relativity DBMS can set the data item to the "SET TO FALSE" value. For other condition-names, the Relativity DBMS cannot determine any particular value to set; the value must be determined some other way.
As a result, if a filter expression contains factors with multiple subexpressions, or if some of the subexpressions are complemented condition-names that do not specify "SET TO FALSE" values, the Relativity DBMS cannot force the filter expression to be true. If the table definition and/or file definition do not provide some other means to cause the filter's value to be "true", the filter expression may never be true. Under such conditions, it may not be possible to insert any rows in the table.
Lastly, some record types may be excluded from consideration by examining which columns are given values (not null), either explicitly or a column default. If a column is defined on an item that is absent in one or more record types, the column is null for any record with one of these record types. Therefore, if an INSERT statement sets a column to a (not null) value, these record types may be ignored; their filters need not be tested.
Note The Nullable Column utility provides a way to determine the status of null information within the catalog.