OLE DB and programming language dependency (vs ADO)

Question

The book in this StackOverflow question states:

Keep in mind that OLE DB was designed for software vendors who develop data-based applications to expose that data to you, an end-user developer, through a consistent interface. OLE DB is fast, efficient, and powerful. It has everything a developer looks for in a data-access technology. It offers access to any data source known to man (or to Windows, for that matter), and it provides access to these data sources with a consistent interface, regardless of data source. The problem with OLE DB is that, like ODBC, it is inaccessible to Visual Basic and other developers, because it is based on a C-style API. Visual Basic developers, in particular, needed more.

1.1.3

ADO Enter ActiveX Data Objects (ADO). ADO, an application-level interface to OLE DB, is the latest, greatest piece of Microsoft's UDA strategy. It combines the best features of its predecessors, DAO and RDO, and adds OLE DB accessibility for VBA programmers. ADO provides a consistent, language-independent means to access data from almost any source, including text-based or other legacy data in relational and nonrelational formats. (You can now see why I needed to explain some of the alphabet soup before getting to ADO itself.)

But looking at OLE DB reference, OLE DB reference consists of COM interfaces.

1. If OLE DB reference consists of COM interfaces, doesn't that mean that OLE DB is language independent, because the whole purpose of using COM is to make things language independent?

2. Why would one call OLE DB a C-style API, if that API consists COM interfaces - those interfaces have methods, and thus those interfaces are already kind of like objects in the object oriented programming? (vs C-style API, which I would associate more with a bunch of functions)

3. If OLE DB is language dependent, what are the languages which can use OLE DB API? (is it C or C++ or both or perhaps others too)

4. If one can create an instance of an OLE DB interface with the CoCreateInstance() function, couldn't that same function (or its compartment in VB) be used in Visual Basic to create the instance of that interface in VB?

Answer 1

It is common (if perhaps misleading) to refer to fully-featured COM interface as "C-style".

To be more precise, the OLE DB interfaces are COM interfaces, yes, and they are 100% language-independent, as long as your language of choice fully supports COM. However, they are not Automation-compatible interfaces.

Visual Basic only supports a subset of everything that COM supports. There are things you need to do to use the OLE DB interfaces that are not supported by Visual Basic.

Consider IRowset::GetData, for example. It takes a void* to a previously allocated memory buffer of the correct size to hold the record. There is no easy way to provide that in Visual Basic.

It's even worse for VBScript, as it requires you to handle all data via Variants. OLE DB uses native type like int which VBScript cannot provide.

By contrast, ADO is a wrapper layer that is automation-compatible, and can be used from VB6, VBScript and VBA.