If you are going to use the client cursor engine then often it’s a good idea to disconnect your recordset…
Disconnected Recordsets
The normal procedure for using the Client Cursor Engine is to open your recordset with client side cursors and then disconnect it from the data source. This causes the CCE to pull all of your data out of the data source and effectively marshal it by value to your client.
Making the ADO Client Cursor Engine believe that your rowset is updateable involves jumping through a few extra hoops…
Client Cursor Engine Updates
It turns out that supporting updates through the client cursor engine is relatively easy. Discovering that it’s relatively easy was extremely difficult. An article that was recently added to the MSDN gives complete and full information on what a rowset needs to support for updates via the CCE to be possible.
The ATL OLE DB Provider templates only seem to support read-only rowsets, and making them support updating of data isn’t as easy as you’d expect!
Cursors everywhere
First it’s worth clearing up some confusion about client and server side cursors and our rowset. Normally selecting either client or server side cursors is a simple choice between network traffic and local storage. Server side cursors are physically located with the data and in the case of most OLE DB providers that’s probably on the far end of a network connection to your database server.
Adding bookmark functionality is relatively easy and it enables our ADO recordset to be used with a greater number of data bound controls.
IRowsetLocate and bookmarks
To support some of the more demanding data bound controls we need to support bookmarks. The proxy rowset that we developed in the last article already has some support for bookmarks built in, but the rowset itself doesn’t expose IRowsetLocate, or the bookmark related properties, so the bookmark functionality can’t be used by consumers.
The ATL OLE DB Provider templates appear to rely on the fact that your data is kept in a simple array, but that’s not really the case at all!
Implementing a custom OLE DB rowset
This article continues from where we left off in the previous article. We have all of the framework in place to provide ADO recordset interfaces on our simple data object. All we need to do now is replace the wizard-generated OLE DB rowset object with one that allows us to access our object’s data.
ADO seems to be the ideal way to expose tabular data from your own COM objects and the ATL OLE DB Provider templates can help!
The problem
If you already have a COM object that manages data that is naturally tabular, or, if you have a COM object that has data which is often displayed in a tabular form then it would seem sensible to leverage the work being put into ADO by third party data control manufacturers.
