Controlling the Update Process

Before any processing of modified rows starts on the server, it fires the BeforeUpdate event. This event is fired on the server, in the same manner as the BeforeUpdateRow/AfterUpdateRow events, but, unlike them, it is fired only once. Its DataSet argument contains the data set passed to the server for update. By modifying this data set, developers can customize the update process and control the set of rows and field values that undergo the database update. The C1DataSetLogic component whose event is fired corresponds to the client-side C1DataSet component that originated the update.

After the BeforeUpdate event, DataObjects for .NET starts scanning all modified rows in a certain order and applying the changes to the database. For more information, see Update Process on the Server. Before processing each row, it fires first the C1DataSetLogic.BeforeUpdateRow event, then the C1TableLogic.BeforeUpdateRow event. The C1DataSetLogic component whose event is fired corresponds to the client-side C1DataSet component that originated the update. The C1TableLogic component represents the simple table containing the row in question.

Using C1TableLogic.BeforeUpdateRow is more common than using C1DataSetLogic.BeforeUpdateRow. A C1TableLogic component represents business logic pertaining to a certain table regardless of the data set where it is used. However, if you need some specific logic depending on the data set context, use the C1DataSetLogic.BeforeUpdateRow event. This, of course, applies to the C1DataSetLogic.AfterUpdateRow event as well.

Both BeforeUpdateRow events have Status argument. Setting it to Skip allows you to cancel further processing for the current row.

After processing the row as described in Generated SQL Statements, DataObjects for .NET fires the C1TableLogic.AfterUpdateRow event and C1DataSetLogic.AfterUpdateRow event, in this order. For more information, see Generated SQL Statements. The values in its Row argument are the values that are later passed back to the client as the current database values in the process of refreshing the rows after update, see Changing Data as a Result of Update (Refresh). Changing the values in the AfterUpdateRow event allows developers to control the refreshed values, if necessary.

Finally, when all rows are processed, the AfterUpdate event is fired. Among other possible uses, it allows you to control the whole data set (via its DataSet argument) sent back to the client for refreshing updated rows, see Changing Data as a Result of Update (Refresh).

All these events, BeforeUpdate / AfterUpdate and BeforeUpdateRow / AfterUpdateRow are server-side events. They fire on the server only. See Application Configurations for the description of DataObjects for .NET client and server. However, this does not apply to a direct client situation, where a 2-tier application updates the database directly from the client, an application where C1SchemaDef and C1DataSet components reside on the same design surface. In this case, the client and the server are one and the same application.