PRB: Client Cursor Engine May Not Asynchronously Fetch Against a Custom OLE DB Provider (268797)
The information in this article applies to:
- Microsoft Data Access Components 2.5
- Microsoft Data Access Components 2.6
- Microsoft Data Access Components 2.7
This article was previously published under Q268797 SYMPTOMS
When you use ActiveX Data Objects (ADO) and set the CursorLocation property for Connection or Recordset to adUseClient, and specify asynchronous fetching with adAsyncFetch and adAsyncFetchNonBlocking for the execution options of the Execute or Open method, the client cursor engine creates a background thread to fetch data from the OLE DB Provider. With a custom provider, you may see the data fetched synchronously (the call to Execute or Open doesn't return until all of the data has been fetched).
CAUSE
Because the cursor engine fetches from the provider on different threads in the asynchronous case, the provider is required to return DBPROPVAL_RT_FREETHREAD for the rowset property DBPROP_ROWTHREADMODEL.
RESOLUTION
To allow the background fetching, a provider must return DBPROPVAL_RT_FREETHREAD for the rowset property DBPROP_ROWTHREADMODEL. This is necessary because the cursor engine is creating a secondary thread, which will continue fetching the data from the underlying rowset. The cursor engine is ensuring that apartment model rules are not being broken.
STATUS
The behavior is by design.
| Modification Type: | Major | Last Reviewed: | 5/12/2003 |
|---|
| Keywords: | kbDatabase kbprb kbProvider KB268797 |
|---|
|