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.
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.
This topic is a part of: