Structured storage also allows DataObjects for .NET to solve another very important problem that other data frameworks fall short of solving in full: the problem of updateable views. Virtually all database applications, especially their GUI front ends, encounter this problem in one way or another. In ADO.NET, as in most previous SQL-based frameworks, it is solved by placing the responsibility for updating a multi-table data view (rowset) on the developer. Unless a rowset (ADO.NET DataTable) is based on a single database table (which is rarely the case in GUI applications), developers must write custom code to send modifications to the database. This is almost taken for granted, as if there is no other solution to this problem causing a lot of tedious manual coding. In fact, the solution exists and has been known for a long time to previous generations of application builder tools. Unfortunately, it has been abandoned if not forgotten. DataObjects for .NET restores the data structure paradigm to its rightful place and with it comes the solution to view updatability.

As we already know, imposing structure on rowsets (composite tables) originating from multiple database tables (as opposed to structureless DataTable of ADO.NET) ensures data consistency and synchronization that would otherwise require manual coding. The same structure helps to solve the update problem. In fact, using DataObjects for .NET, you will rarely write any code related to database updates at all. In most cases, database updates will be performed automatically by DataObjects for .NET in the exact way they are required by the data model. When your application sends updates to the database (Update), DataObjects for .NET collects all modified simple table rows and sends them to the server for update (commit).

Note that simple table modifications are sufficient for the update process. We do not need to be concerned with where those modifications came from. The user might use a simple table view or a composite table view to modify a row of a simple table, it does not matter. All that matters is that a simple table row has been modified (or inserted, or deleted). Before the update, DataObjects for .NET has already resolved the problem that other tools must resolve during Update: using the data structure, it has already determined which rows of which simple tables have been modified by the end user changes. Therefore, all that remains is to send those simple table modifications to the database, applying each of these modifications to the corresponding database table. Only simple table rows are involved in this process. Complex objects, such as composite tables and table views are not involved in update.

Consider the Customer-Orders-Employees example of Structured Data Storage: Tables and Table Views, the user could modify some rows of the CustOrders composite table (using a grid control showing the combined customer-order-employee information), and also add and delete some rows. Since CustOrders is a composite table, it means that some Customers rows could have been modified, as well as some Orders and some Employees rows. Additionally, other modifications to these simple tables can be made in the same session via other table views. All these modifications are basically modified rows of the simple tables. Therefore, DataObjects for .NET already knows what database table rows must be modified, added or deleted to commit this transaction. It goes to the server and does just that, applies the modifications to the database tables Customers, Orders and Employees.

For details on the process of committing changes to the database, including possible customization of the update process with your business logic code, see Updating the Database.

Note that in addition to the batch update mode, standard in distributed applications, where database updates are performed only when explicitly requested by a special method call (when the user presses a button, for example), DataObjects for .NET also supports the classic automatic update mode. This mode, familiar to developers of classic client-server and desktop applications, ensures that all changes made in the current row are committed to the database when the end user leaves this row, moves to another row in a table. This mode is not supported in ADO.NET and standard Windows Forms data binding. It is correct that this mode is unsuitable for distributed applications. However, many existing designs depend on it, and it is very well suited for desktop applications. DataObjects for .NET adds yet another enhancement to the .NET data framework by implementing the automatic update mode. By default, all DataObjects for .NET data sources work in batch update mode. But if you use C1DataTableSource as your data source, and set its UpdateLeavingRow property to True, it will perform update automatically when the end user leaves a row after modifying it.