Executing Optimistic Batch Updates

RDO 2.0 implements a new technique to submit multiple database operations as a batch. The ODBC and SQL Server server-side cursor libraries both support multiple statement batches against data sources that support this concept. However, the individual operations are not managed by the cursor driver, so errors and other contingencies must be handled manually. In contrast, the Client Batch cursor library is designed to automatically:

• Track the status of each row in rdoResultset objects it creates. As each row is changed or deleted or new rows are added, the Status property is automatically set to reflect that the row is "dirty." By examining the row status, the Client Batch cursor library can track those rows that have been added, changed, deleted, or unchanged.
  
  
• Manage independent rdoResultset objects. While an rdoResultset cannot be created independently from saved local data, once a static result set is created, you can disconnect from the remote server and perform any number of changes to the rdoResultset object. You can then re-associate the rdoResultset with another connection by setting the ActiveConnection property, and use the BatchUpdate method to post the changes.
  
  
• Permit postponement of the update operation. Because the Client Batch cursor library is designed to operate on an entire set of rows as a batch, you can delay posting the changes to the database for as long as necessary.
  
  
• Build the SQL statements needed to perform the database changes. Basically, the Client Batch cursor library appends a suitable WHERE clause to each SQL statement to correctly identify specific rows by key.
  
  
• Manage the result of each operation and report the success or failure status back to your application.

Basically, when using a deferred update strategy as described here, you generally assume that the data involved is not subject to significant changes while the offline or deferred operations take place. If, on the other hand, the data is being constantly queried and changed, this strategy quickly breaks down. The Client Batch cursor library is designed to trap collisions that occur when unexpected update conflicts occur — as when another user changes a row that is a member of the result set being updated. When this happens, each row involved in a conflict is marked and all three copies of the data are made available to your application:

• The data as it was when first read by your application from the database.
  
  
• The data as it is now recorded in the database — as the other user changed it.
  
  
• The data which your user attempted to save.

Using these three versions of the data, it is your application's job to reconcile the differences.