Physical database update in smartBatchUpdate

Last month, I’ve posted an in-depth discussion on SmartBatchUpdate, a new major feature that we’re going to introduce in the next major version of WebGrid. While the previous post is more focused on the UI/X aspects, this post will focus more on the server-side, its programmability and behind-the-scene process on the batch update.

SmartBatchUpdate™ provides sophisticated implementation to automate the batch updating process to the physical database.

The automatic updating feature significantly reduces development time – as you are not required to write any codes to perform the batch update, or very minimal efforts when you need to customize the updating process in more advanced scenarios. To understand the physical updating concept better, please see the following illustration.

Understanding Batch Update Process

As shown in the illustration above, the physical update has several processes such as detailed in the following:

• Automatic object updates

This setting is enabled by default. This feature will attempt to automatically apply the submitted pending changes to the intermediate data source that hold the objects during the binding process.

For instance, when WebGrid is bound to DataSet or DataTable, your pending changes will be applied and then mapped to your data source. This enables you to simply call a line of code to perform the physical updates via DbAdapter.

In more advanced scenario, such as when WebGrid is bound to unstructured data source or custom object, you can disable this feature by setting the AutomaticObjectUpdates property in BatchUpdateSettings to false.

In addition to single table support, this feature is also designed to support nested hierarchical tables that linked through Referential Integrity. This feature makes advanced scenarios possible such as cascading inserts and other scenarios related to hierarchical tables.

Please note that WebGrid doesn’t perform physical update in this process.

• BatchUpdate server side event.

WebGrid provides a new server side event named OnBatchUpdate, which is invoked when the pending changes are required to be submitted to physical database.

When bound to data source other than data source controls, developers can handle OnBatchUpdate server side event to write the codes required to update the changes into physical database.

When bound to updatable data source controls – such as AccessDataSource, ObjectDataSource, and others – WebGrid will handle all physical updates automatically, given that ReturnValue is true in OnBatchUpdate event. The ReturnValue is true by default, which can be set to false to cancel automatic physical updates.

OnBatchUpdate server side event provides BatchUpdateEventArgs in the event argument, which is useful for developers who would like to customize the physical updating process, such as in the case of custom object binding.

• Partial errors support.

In addition to solid batch update architecture and automatic object updates, SmartBatchUpdate™ is also equipped with support for partial errors, making it the most advanced and reliable solution for client-side data editing application.

Partial errors occurred when one or more changes are failed to be updated while there are also some successful updates. Partial errors will not occur when all changes are failed.

With partial errors support, user can make changes with confidence, without have to worry that error in one of the changes will cause all changes to fail. This means that WebGrid is able to isolate erroneous changes, and continue to update the next changes that are unrelated to the previously failed changes update.

The following image shows a WebGrid with partial errors response. The error detail for each failed updates are shown in the message box, making it easy for end user to review and revise the errors.

 

For more control over partial errors response in the client side, you can handle the OnBatchUpdateSuccess client side event and access the rowErrorXml parameter to get the error detail on each failed update.

Various Datasource Support in Batch Update

WebGrid Enterprise 7 supports physical database updates in various scenarios, such as when bound to different type of datasource, hierarchical tables configuration, and more. The following list describes the supported scenarios in more details:

• Traditional Binding (ADO.NET DataSet and DataTable)

When bound to ADO.NET-compatible data source such as DataSet and DataTable, you will need to write codes in OnBatchUpdate server side event to update the changes to database.

However, the required codes should be very minimal as ADO.NET already implemented batch update at data access level. Developers will then be able to simply invoking a single Update method to process all changes, which were previously mapped during Automatic Object Updates process.

The following C# codes show how to update all changes that bound to a DataTable object.

void WebGrid1_BatchUpdate(object sender, BatchUpdateEventArgs e)
{
CustomersTableAdapter daCustomer = new CustomersTableAdapter();

DataTable dt = (DataTable)WebGrid1.GetCachedDataSource();

daCustomer.Update(dt); // updates all changes to database

}

• Declarative Binding (Datasource Control such as SqlDataSource)

Data source control is the most ideal data binding concept in ASP.NET that provides clear abstraction between UI and data logic. Introduced in .NET 2.0, data source control allows you to bind data in declarative markup, saving you from tedious tasks and lengthy codes.

SmartBatchUpdate™ takes advantage of data source control to the fullest. When you connect WebGrid to an updatable data source control, you don’t need to write codes to handle the physical updates.

• Hierarchical Traditional Binding (ADO.NET DataSet)

Similar to Traditional Binding, you are also required to handle OnBatchUpdate server side event to write codes to perform database updates.

Thanks to the automatic identity’s mapping through referential integrity, WebGrid performs all the complex logics behind the scene, so that you only need to write a few lines of codes to update the dataset.

• Hierarchical Declarative Binding (ISDataSource)

As in flat WebGrid declarative binding, SmartBatchUpdate™ supports hierarchical WebGrid that is bound to ISDataSource control in the same way and consistent fashion.

With ISDataSource control, you are not required to write codes in order to perform physical update into the underlying database.

It is important to ensure that your ISDataSource instance has been properly configured to return new identity for each table in the event of insert.

• Custom Object

In addition to built-in .NET data sources, batch update is also designed to support advanced enterprise scenarios, such as using the feature in conjunction with custom object data binding.

When bound to custom object collection – such as a list of Customer objects – you can disable automatic object updates feature. In this case, you are responsible to write codes to perform physical updates according to your business logic/model.

In the same way as in other data sources, you handled OnBatchUpdate server side event to provide codes to perform physical update.

Conclusion

With multitude of batch update features and data source support, WebGrid 7 provides the most comprehensive features for all data editing needs – taking account compatibility with hundreds of existing features as well as support for new scenarios. As Web developers, you got the power, flexibility and speed that you need to build your next-generation, Web 2.0-ready applications.

There are so much more about batch update that I can’t detail here. I believe it’s best for you to try and experience it yourself when the beta bit is out sometime next week.

In my next post, I’ll try to delve more on new client-side binding technology along with its dozens of breakthrough features. Stay tuned!

All the best,
Jimmy.