The same business logic events, such as AfterFieldChange or BeforeDelete, can be handled on different levels:
| Level | Description |
|---|---|
| Simple table level | Events of a C1TableLogic component (see Table Business Logic Events). They are triggered in any context, wherever the table is involved: in a composite table including this table, and in a table view based on this table. For example, if you write code converting CustomerID value to upper case in table_Customers_BeforeFieldChange, it will work for the Customers table itself, and for a CustomersOrders composite table that includes Customers, and for any table view based on such tables. In other words, the business rule will be automatically enforced everywhere it should be, in any possible context where the Customers table is used. |
| Composite table level | Events of a C1TableLogic component representing a composite table. They are triggered in any data set where the composite table is used. They are not triggered for constituent simple tables when they are used outside of this composite table context. For example, if you write some code in a CustomersOrders composite table event, it will be executed when the user works with CustomersOrders, but not when they work with the Customers table stand-alone. |
| Table view level | Events of a C1DataSetLogic component (see Table View Business Logic Events). They are active in a particular data set. If there are multiple C1DataSet objects with the same schema definition (DataSetDef; see Schema Objects), they are active in any such object. This business logic level represents data set-specific (in other words, table view-specific) rules that must be enforced in the context of a particular data set and table view, but do not always apply to the underlying table. |
| Rowset level | Events of a C1DataTableSource control. This level is different from all the rest in that it belongs to a particular client application, as opposed to a data library. All other logic levels are enforced by DataObjects for .NET in any application that uses their data library. Rowset level logic is enforced only in the application where this code is written. |
Consider for example, a CustomersOrders composite table, including a simple Customers table, and a data set MyOrders having MyOrdersView table view based on the CustomersOrders table. Imagine a form in a client application with a C1DataSet dataSet1 connected to MyCustomersView, a C1DataTableSource C1DataTableSource1 connected to dataSet1, and a grid bound to C1DataTableSource1. Imagine that we have business logic event code BeforeFieldChange specified on all levels. When the end user modifies the CustomerAddress field in the grid (the field belongs to the Customers table inside the CustomersOrders composite table), the order in which the events are triggered will be from the most specific to the most general:
C1DataTableSource1_BeforeFieldChange (rowset level) →
dataset_ MyOrders_BeforeFieldChange (table view level) →
table_CustomersOrders_BeforeFieldChange (composite table level) →
table_Customers_BeforeFieldChange (simple table level)For the corresponding "after" event, AfterFieldChange, the order will be the inverse, from the most general to the most specific:
table_Customers_AfterFieldChange (simple table level) →
table_CustomersOrders_AfterFieldChange (composite table level) →
dataset_ MyOrders_AfterFieldChange (table view level) →
C1DataTableSource1_AfterFieldChange (rowset level)