Visibility of Pending Changes

If the consumer completely releases and then refetches a row that has a pending update or delete, the visibility of that pending update or delete depends on the values of the DBPROP_OWNUPDATEDELETE, DBPROP_LITERALIDENTITY, and DBPROP_REMOVEDELETE properties.

If DBPROP_OWNUPDATEDELETE and DBPROP_LITERALIDENTITY are both set to VARIANT_TRUE, pending and transmitted updates and deletes are visible when rows are fetched. If DBPROP_REMOVEDELETE is also set to VARIANT_TRUE, rows with pending or transmitted deletes are not returned when rows are fetched.

If DBPROP_OWNUPDATEDELETE is set to VARIANT_TRUE and DBPROP_LITERALIDENTITY is set to VARIANT_FALSE, only transmitted changes and deletes are visible when rows are fetched. If DBPROP_REMOVEDELETE is set to VARIANT_TRUE, rows with transmitted deletes are not returned when rows are fetched, but rows with pending deletes usually are returned.

If supported, the property DBPROP_CACHEDEFERRED controls when column values are fetched. If DBPROP_CACHEDEFERRED is set to VARIANT_TRUE, changes made via a different row handle are not seen until IRowsetRefresh::RefreshVisibleData is called.

For more information, see "Uniqueness of Rows in the Rowset" in Chapter 4: Rowsets.

Whether methods that fetch rows can retrieve pending insert rows (that is, rows that have been inserted in deferred update mode but for which IRowsetUpdate::Update has not been called) depends on the DBPROP_RETURNPENDINGINSERTS property.

Note   Many providers cannot return pending inserts because they use the row-returning mechanisms of the data store. Because pending inserts have not yet been transmitted to the data store, the mechanisms there cannot return them.