Tag Archives: Batch Update

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.

Batch update processing

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.


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,

Batch Update in WebGrid Enterprise 7

Earlier this year, I’ve written a blog post discussing briefly on our next-generation data visualization components for Silverlight and ASP.NET platform. In this post, I’ll discuss about WebGrid 7’s major features in more details, specifically on batch update.

Over the past years, we have received tremendous requests for WebGrid to support built-in batch updating. Batch update is a data updating mechanism that processes multiple edits in a single request. Compared to the default update mode, batch update offers numerous benefits that makes it an essential feature in today’s most demanding Web 2.0 application. Some of the benefits are:

  • Richer experience. With batch update, users can perform data editing faster and more intuitive as there’s no more wait-time for each update.
  • More resources efficient. Instead of sending update to server on each changes, batch update sent all changes in a single request. That means less server overhead and less bandwith consumption.
  • Streamlined data validation and error handling. Batch update lets you perform data validation more efficiently in centralized event against multiple table changes, makes it easy to handle transaction errors.
  • Offline capability. With a proper batch update implementation, users can take their application offline, make changes locally, and synchronize the changes to server when it becomes available.

WebGrid Enterprise® 7 — which will be shipped in the upcoming WebUI Studio 2009 R1 volume release — includes comprehensive batch update features, such as discussed in the following sections. This first post on batch update will cover the feature overview, pending changes concept and built-in changes management.

Introducing SmartBatchUpdate

SmartBatchUpdate is a new feature in WebGrid Enterprise 7 which enables you to perform multiple edits across multiple tables in real-time without postback/callback. All pending changes will be submitted into server at once with a single AJAX callback, thus eliminates waiting time and improves data editing experience in overall.

The batch update feature in WebGrid 7 is specifically designed to achieve several key objectives below:

  • Robust and reliable client-side storage for storing changes.
  • Extensible architecture and API for batch update management in both client and server side.
  • Works in conjunction with in-line editing architecture to provide the richest editing experience.
  • Submit all updates in a single AJAX request via built-in WebGrid user interface, or via API.
  • Automatic changes persistence, allowing changes to be preserved as users perform navigation.
  • Support hierarchical tables by using same architecture and pattern, as well as supporting cascading inserts and deletes.
  • Intelligent support for identity management in cascading inserts (creating new rows in several tables respectively).
  • Ability to let users perform undo changes.
  • Works flawlessly with existing features, such as sorting, filtering, paging and hundreds of UI features.
  • Allow users to review all pending changes in a dialog box interface, primarily useful when used in conjunction with paging.
  • Full support for new client-side binding and data services such as Web service and WCF service.
  • Full support for ADO.NET Data Service (also known as Astoria). 

Pending Changes Concept

SmartBatchUpdate™ used state-of-the-art pending changes concept to provide solid functionality and architecture for its batch update features. With the concept, every row that has changed since its first load will result in a pending change. A record row can contain only one pending change at a time, which is one of four modes below:

  • Unmodified. When a change is undo’ed, the record will be set back to Unmodified.
  • Added. Newly added row will be marked as Added pending change.
  • Modified. Edited row will be marked as Modified pending change.
  • Deleted. Deleted row will be marked as Deleted pending change.

Each row’s pending change is stored based on its corresponding table. This means that each table contains one or more pending changes which are associated with each logical row. As a result, SmartBatchUpdate™ provides solid and consistent object models and interfaces which enable pending changes to be consumed in multiple tables (hierarchical) configuration.

The following illustration describes the pending changes concept in a hierarchical Grid.

Pending changes concept in WebGrid 7

Pending changes are stored locally on client-side and can be accessed programmatically through client-side API.

Furthermore, pending changes are automatically restored and synchronized with the current view whenever the Grid performed a FlyPostBack action – such as sorting, filtering, grouping, etc – or page full postback. This provides users with greater experience to interacting with information while maintaining current changes simultaneously.

SmartBatchUpdate™ also includes built-in pending changes management, such as ability to undo changes, accept changes, as well as review changes. The following discusses the built-in changes management in details.

Built-in Changes Management

SmartBatchUpdate™ provides a high-level built-in changes management, in addition to the solid underlying infrastructure which maintains the integrity and consistency of pending changes and batch update process.

Changes management in WebGrid Enterprise 7 includes the following features:

  • Undo Changes.

WebGrid stores all pending changes and all its associated row objects in client side. This design enables WebGrid to track the changes made on each record. Therefore, it allows users to undo a pending change completely.

Undo changes feature in WebGrid 7

You can access Undo Changes command by bringing the row’s context menu (right click on selected row). If you would like to undo all changes that you have made, you can click on Undo All Changes command in the row’s context menu. Alternatively, you can easily locate the command in the status bar.

Please note that undo changes command will revert all changes back into its original state. Thanks to the state-of-the-art pending changes architecture, the operation is done in real-time without the needs for server postback/callback.

  • Review Changes.

Designed with solid architecture, SmartBatchUpdate™ allows your end user to make dozens to hundreds of pending changes in a single session.

For instance, end user is allowed to make changes from one page, navigate to other page through paging function and make changes on the other pages, and so on. With so many changes in different views, users often have difficulty in reviewing or locating the pending changes.

To support these dynamic scenarios, users will need the ability to access all pending changes that they have made in different views. Review Changes is a powerful runtime feature that makes it easy and efficient for users to review all changes regardless of the tables and pending changes state.

Review Changes feature sports sleek dialog box interface to provide end user with a streamlined and convenient access to all pending changes within a single location. See below screenshot to get a better picture.

Review changes feature in WebGrid 7

Review Changes dialog box provides easy-access to all pending changes across tables and views – makes it easy
for users to undo several records or accept changes.

Note that the changes will be preserved even though the view has changed completely – eg, through sorting or paging.


By now, you should already have insights on what batch update is about, how it works, and how it could bring significant benefits to your Web application. I hope you enjoy reading this blog post and that it gives you more ideas on how you can take advantage of these features in applications.

In the next post, I’ll cover more technical aspects on the batch update feature such as how WebGrid 7 elegantly handles the batch update in various data sources – from datasource control to custom data object. I’ll also detail some interesting features such as the batch update support on hierarchical configuration, and how we handled cascading inserts automatically in hierarchical table. So stay tuned!

All the best,