12.2.1- What is OLE-DB?

What is OLE-DB?

OLE-DB is the next step in the evolution of the anonymous data store. As well as being more generic than ODBC, Microsoft has done a great deal of work to ensure that OLE-DB is faster and easier to use than ODBC. Eventually it may well replace ODBC, although that won't be for a long time yet, if only for the reasons that you often have to rely on third parties writing new OLE-DB providers and then when they are available they are often more expensive than existing ODBC drivers. So, consequently, there's a lot more ODBC drivers out there still in use.

The following diagram begins to build up a picture of data access using OLE-DB:

As you can see, the idea behind OLE-DB is very similar to the idea behind ODBC – but in fact it allows access to a much broader range of data stores. In fact, you'll notice that OLE-DB even supports database connections through ODBC – so that effectively your generic OLE-DB layer will allow you to connect to your legacy databases through your existing ODBC connections.

Data Providers and Data Consumers

OLE-DB introduces the notion of data providers and data consumers. The relationship between a data provider and a data consumer is fairly obvious: a data provider is something that provides data, and the data consumer is something that uses that data. In reality, you might have several data providers – one for each different type of data store.

At the time of writing, Microsoft itself has made available quite a number of OLE-DB providers for different types of data store, including data providers for their Access, SQL Server, Oracle, Exchange Server, Excel and Foxpro. If you're interested in other external OLE-DB providers here's a list of some of the companies currently in the market:

Don't worry if you're not familiar with some of these names. The point to take from all this is that, although this is a fairly new technology, it's got a lot of industry support.

As we said above, the data consumer is just something that uses the data that the data provider provides. So, in this book, the data consumers will be our ASP pages (or more specifically, the ADO objects within our ASP pages that will manipulate the data for display on the page). In another context, we might use the OLE-DB data providers to provide data for other data consumers, such as an application written in a language like Visual Basic or Visual C++.

ASP and OLE-DB

In fact, each OLE-DB data provider is a unit of code, written in a language such as C++ or Java, which uses OLE-DB objects to provide the instructions required to communicate and pass data between the data store and the data consumer. Once you know this, you may be tempted to ask: "Why don't we use the OLE-DB objects directly within our ASP pages, and cut out these OLE-DB providers?"

There's a good reason: the OLE-DB objects themselves are very low-level objects. Scripting languages like VBScript (and even languages like Visual Basic), are simply not sufficiently powerful to allow us to manipulate the OLE-DB objects (although, of course, languages such as C++ and Java are!). That's why we take advantage of the data provider/data consumer mechanism, to pass the data between the data store and the ASP page across a number of intermediate layers.

We've already discussed the data providers – but what of the data consumer? It comes in the form of a set of objects known as the ActiveX Data Objects (or ADO). ADO is an interface that allows our ASP pages to talk to OLE-DB. So, when we use ASP to talk to a data store, we're actually using ASP to talk to ADO, which in turn talks to OLE-DB, which in turn gets information from our data store.