Immediate vs. Delayed Update Mode

Whether the consumer uses immediate or delayed update mode depends on how many consumers share the rowset and how they use the rowset. In most cases, the primary user of immediate update mode is a single consumer that wants to transmit changes immediately to the data source. Consumers use delayed update mode for many reasons, including the following:

• Shared rowsets—If multiple consumers share a rowset, they often use notifications to coordinate multiple changes. By using delayed update mode, consumers can coordinate their changes locally in the rowset before transmitting them to the data source.
  
  
• Multiple changes to the same row—If a consumer makes multiple changes to the same row, such as when multiple accessors are used or when users input changes at different times, the row might be left in an invalid state. For example, if a key consists of several columns and each column is changed in a separate call to IRowsetChange::SetData, the intermediate states might be invalid. By using delayed update mode, the consumer can buffer these changes in the rowset before transmitting them to the data source.
  
  
• Network traffic—If a rowset resides on one node in a network and the data source resides on another node, transmitting changes from the rowset to the data source requires a network call. By using delayed update mode, the consumer can bundle together changes to multiple rows and send them across the network with a single call to IRowsetUpdate::Update. This is particularly critical for wide area networks such as the Internet, on which network calls are very expensive.
  
  
• Undoing changes—IRowsetUpdate::Undo enables the consumer to undo pending changes. By using delayed update mode, consumers can expose an undo capability to users without having to implement it.