Share via


Updating Behavior

Important

This feature will be removed in a future version of Windows. Avoid using this feature in new development work, and plan to modify applications that currently use this feature. Applications should instead use WCF Data Service.

The OLE DB Remoting Provider can support batch updating if the underlying OLE DB provider is SQL-based.

Updates, if supported, are based on optimistic concurrency control semantics.

When the rowset is returned to the client, its original, underlying, and current values are all saved. At first, each of these values is identical for the fetched row. When the row is changed on the client, only the current value is modified. When an update is attempted, the underlying value is compared with that in the data store. If the values are identical, the update proceeds. If they are different, which means the data store value has changed, the update fails and RowStatus is returned. Status is given only for those rows with update conflicts. At this point, you can either resynch the row to obtain the data store value or abort the update operation. Fetching the row again, using resynch, will change the underlying value but not the original or current values.

Comments

The RowStatus array is returned by the IRowsetUpdate::Update or IRowsetRefresh::RefreshVisibleData methods. When an update of the data store fails, RowStatus identifies the rows that failed in the same order as the rows sent.

See Also

Reference

Updating Data in Rowsets (OLE DB)

IRowsetRefresh::RefreshVisibleData

IRowsetUpdate::Update

Refreshing Row Data