Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Asynchronous Processing (OLE DB)

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 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.

Show:
© 2015 Microsoft