As with simple tables, fetching data for composite tables originates from table views based on the composite table, see How the Data is Fetched. The resulting composite table rowset is the union of rowsets fetched by table views based on this composite table.

Fetching composite table data, DataObjects for .NET generates a SQL statement joining all involved simple tables with SQL joins. This is only possible if all constituent simple tables are bound tables sharing the same Connection. For more information, see Bound, SQL-Based and Unbound Tables. By default, this is a necessary condition for a composite table; it will throw an exception if this condition is not satisfied. However, by setting a special property AllowMultipleConnections to True you can override this restriction. Then DataObjects for .NET will apply a nested loop algorithm to fetch the composite table data from different database connections and/or from unbound data sources. The result will be the same as if all the data were stored in the same database, with the same connection, but performance may be much slower than with a single SQL statement.

The process of generating the SQL statement fetching data is automatic, but it can be affected by a few properties:

• OuterJoinInManyToOne (default: True): By default, many-to-one relations in a composite table diagram generate outer joins in the SQL statement. This ensures the standard interpretation of many-to-one links, where the child table contains one row corresponding to the parent row, or none. If there is no corresponding row, the child fields receive null values. However, some databases do not implement outer joins, or implement them inadequately, with various limitations. In this case, and when outer joins are undesirable for other reasons, you can set this property to False. DataObjects for .NET will use inner joins for this view relation in the composite table diagram. Note that one-to-many relations always produce inner joins in the generated SQL statement. This is because every composite table row must contain non-null values for all its primary key fields, and that requires that for every one-to-many relation at least one child row exists for every parent row.
• Alias (default: empty string): A generated SQL statement must use aliases for constituent simple tables, because a table can occur more than once in a composite table diagram, so its name may be not unique in the statement, in which case it needs aliasing. For more information, see Creating and Modifying Composite Table Diagrams. By default, view table names are used as aliases, but if you want to change the default alias, you can set it for a table view in the Alias property. This is rarely needed; this property is added only for completeness, since all other names in the generated SQL statement can be controlled by developers using DbTableName and DbFieldName.

If you want to see the generated SQL statement, set up a C1DataSetLogic component and attach a handler to its AfterGenerateSql event. The generated SQL statement is passed as an argument to that event.

Once the data is fetched, it is stored as described in Structured Data Storage: Tables and Table Views. This structured storage ensures that data is always kept in sync, with the schema structure preserved on all modifications, whether modifications are made from a simple table or from a composite table including that simple table.

When updating data, committing changes to the database does not involve composite tables. As described in How the Data is Modified, all changes end up in simple tables, so it is this simple table data that is sent to the server to update the database.