Asynchronous Processing (OLE DB)

Asynchronous processing enables methods to return immediately without blocking on the calling thread. Consumers request asynchronous processing when initializing a data source object or when opening or populating a rowset. The consumer must explicitly request asynchronous processing. Otherwise, the provider can perform asynchronous operations in the background but must behave synchronously, blocking if necessary, until the underlying asynchronous operation completes.

OLE DB 2.5 providers that support direct URL binding or scoped operations on row objects may also support asynchronous operations. Consumers may request asynchronous processing when binding from a URL to an OLE DB object or when performing scoped operations ? such as copy, delete or move ? on a row object.

Data Source Initialization properties are used when consumers initialize a data source object asynchronously. Consumers wishing to asynchronously open a rowset use the Command Execution and Rowset Generation properties. Consumers wishing to asynchronously populate a rowset use properties of Rowset Population.

For more information on	Go to
Calling thread	Provider Threading Models
Consumers	Conceptual Programming Models in OLE DB
Data source objects	Data Source Objects (OLE DB)
Rowset	Rowsets (OLE DB)
Asynchronously initializing a data source	Asynchronous Data Source Initialization
Asynchronously opening a rowset	Asynchronous Command Execution and Rowset Generation
Asynchronously populating a rowset	Asynchronous Rowset Population
Asynchronously binding from a URL to an OLE DB object	Asynchronous URL Binding
Performing asynchronous scoped operations	Asynchronous Scoped Operations

Consumers can poll for the status of an asynchronous operation by calling IDBAsynchStatus::GetStatus on the object being asynchronously processed, or can register for progress notifications by passing the consumer's IDBAsynchNotify interface to the connection point of the object being asynchronously processed.

Asynchronous processing can occur in phases. If the object is asynchronously initialized, the initialization phase occurs first. While the object is in the initialization phase, it is in an uninitialized state. Attempting to call other interfaces may fail, and attempting to call QueryInterface for interfaces other than IConnectionPointContainer or IDBAsynchStatus may return E_NOINTERFACE.

Once all asynchronous processing has completed for an operation, the provider calls IDBAsynchNotify::OnProgress with ulAsynchPhase set to DBASYNCHPHASE_COMPLETE for that operation, followed by IDBAsynchNotify::OnStop, to notify listeners that asynchronous processing has completed. Any calls to IDBAsynchStatus::GetStatus for that operation return an HRESULT indicating the outcome of the operation, with ulAsynchPhase set to DBASYNCHPHASE_COMPLETE, pulProgress equal to pulProgressMax, and ppwszStatusText set to a provider-specific value indicating completion or NULL.

Note

If a consumer enlists in an asynchronous phase that has already completed, the provider should immediately call IDBAsynchNotify::OnProgress with ulAsynchPhase set to DBASYNCHPHASE_COMPLETE for that operation, followed by IDBAsynchNotify::OnStop, to notify the consumer that asynchronous processing has completed.

If a consumer enlists in an asynchronous phase that was aborted or vetoed, the provider should immediately call IDBAsynchNotify::OnProgress with ulAsynchPhase set to DBASYNCHPHASE_CANCELED for that operation, followed by IDBAsynchNotify::OnStop, to notify the consumer that asynchronous processing has finished but was canceled.