OLE DB

The current method of data access that Microsoft recommends is relatively easy to use as a data consumer, especially from VB.

Writing a data provider is another matter entirely. The OLE DB documentation is mostly written in a style that assumes you're only using it for reference, this makes it hard to get to grips with when you first start working with it.

The ATL OLE DB provider templates offer some help, but, to be honest, as soon as you start to stray from the simple examples provided you find that the supplied templates are very limited.

When we started to write an updateable (read/write) OLE DB provider we found that there was also relatively little information available on the web, even questions to newsgroups failed to provide answers for what appeared to be simple questions.

The design of OLE DB and ADO makes it difficult to debug a provider, they don't use the standard COM functionality discovery mechanism - QueryInterface() - to determine levels of functionality, they ask you for the properties you support. If you answer the question incorrectly you'll never be asked for certain pieces of functionality. At least with QI calls you can see what's being asked of you and keep adding interfaces until everything works... Deciding from the documentation which properties and which interfaces are required is not always easy.

These articles show how to do some things that, I expect, many people want to do with OLE DB and ADO:

• Provide access to an existing data object via an ADO recordset interface. Sometimes you have a perfectly useful COM object that happens to store data that is tabular in nature. It would be nice to expose this data via ADO.
• Keep all of the OLE DB access hidden inside your object, you just expose a completely constructed ADO recordset.
• Provide read/write access to your data via a provider written with the ATL templates.

Articles:

Objects via ADO - 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!

Custom Rowsets - 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!

IRowsetLocate and Bookmarks - Adding bookmark functionality is relatively easy and it enables our ADO recordset to be used with a greater number of data bound controls.

Updating data through an ADO recordset - 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!

Client Cursor Engine updates - Making the ADO Client Cursor Engine believe that your rowset is updateable involves jumping through a few extra hoops...

Disconnected Recordsets - If you are going to use the client cursor engine then often it's a good idea to disconnect your recordset...