Datasheet

OLE-DB
Object Linking and Embedding Database (OLE-DB) was the next big step forward in data providers, and it
is still widely used today. With OLE-DB, Microsoft applied the knowledge learned from developing
ODBC to provide a better data access model. OLE-DB marked Microsoft’s move to a COM-based API,
which made it easily consumable by most programming languages, and the migration to a 32-bit OS
with the release of Windows 95.
As with any code, ODBC became bulky through multiple revisions. The OLE-DB API is much cleaner and
provides more efficient data access than ODBC. Oddly enough, the only provider offered with its initial
release was the ODBC provider. It was just a wrapper of the ODBC provider and offered no performance
gain. The point was to get developers used to the new API while making it possible to access any existing
database system they were currently accessing through ODBC. Later, more efficient providers were
written to access databases such as MS SQL Server directly, without going through ODBC.
OLE-DB Providers
OLE-DB is also much less dependent upon the physical structure of the database. It supports both rela-
tional and hierarchical data sources, and does not require the query against these data sources to follow
a SQL structure. As with ODBC, vendors can create custom providers to expose access to their database
system. Most people wouldn’t argue with the belief that it is far easier to write an OLE-DB provider than
an ODBC driver. A provider needs to perform only four basic steps:
1. Open the session.
2. Process the command.
3. Access the data.
4. Prepare a rowset.
OLE-DB Consumers
The other half of the OLE-DB framework is the OLE-DB consumer. The consumer is the layer that speaks
directly to the OLE-DB providers, and it performs the following steps:
1. Identify the data source.
2. Establish a session.
3. Issue the command.
4. Return a rowset.
Figure 1-1 shows how this relationship works.
5
History of Data Access
03_584375 ch01.qxd 10/28/05 10:49 PM Page 5