MDAC 2.5 SDK - OLE DB Programmer's Reference
Chapter 12: OLE DB Object Notifications
Providers send notifications when changes occur to provider objects, such as rowsets, that are shared by two or more consumers. For example, when several consumers share a rowset and one of them changes the rowset by calling an IRowsetChange method, the provider can notify the other consumers in case they need to refresh their local copies of row data. To receive these notifications, consumers must implement IRowsetNotify and register it on a connection point with the provider, which calls IRowsetNotify methods to send notifications to consumers.
Notifications also can be used to coordinate sets of changes performed by multiple consumers. Often such changes occur in phases, during which participating consumers make changes based on changes made by other consumers in previous phases.
Note Providers do not send notifications when changes are attempted but fail.
Notifications can be nested. That is, sending one notification can cause a consumer to take actions that cause another notification to be sent.
Notifications can also be grouped. For example, providers that support notifications can be instructed to send only two notifications for an operation on multiple rowsets: one for all rows that succeeded and one for all rows that failed. If a provider supports grouping of notifications, it reports a value of DBPROPVAL_NT_MULTIPLEROWS for the property DBPROP_NOTIFICATIONGRANULARITY.
If an action causes the provider to send multiple notifications, all of those notifications must be approved by the consumer before the provider performs the action. If a consumer cancels a single notification, the provider does not perform the action and returns DB_E_CANCELED. For example, if a call to IRowsetChange::SetData changes multiple columns, the consumer must approve the changes to all of the columns before the provider changes any of the columns. If the consumer does not allow a change to any of the columns, no columns are updated. For more information, see the entry for IRowsetChange::SetData in the reference section.
Consumers can screen out unwanted events or phases of an event by returning DB_S_UNWANTEDREASON or DB_S_UNWANTEDPHASE when the provider calls the consumer's IRowsetNotify methods to report the unwanted events. Providers are not required to stop notifying consumers of the unwanted events or phases. However, for performance reasons, providers can choose not to send notifications of unwanted events. Screening out a phase applies only to that particular event. Other events will still send out notifications for all phases unless they are also screened.