DB2 OLE DB Driver

Microsoft is now looking at moving from the ODBC standard for accessing databases and instead has developed a new OLE standard. The OLE standard encapsulates much of the functionality that ODBC provides but takes it one step further. The main purpose of the new standard is to provide access to any data, whether a relational DBMS, a spreadsheet, flat file, or even an email manages that data. Many ODBC vendors are starting off by supplying bridges from an OLE application to their ODBC drivers. DB2 has developed its own OLE driver known as the DB2 OLE DB driver.

OLE defines a set of standard interfaces through which an application can access the services of another (for example, the DB2 DBMS). Each interface defines a set of functions (also sometimes called methods) that allow the application access to these services. For a service to provide an interface it must fully define all functions for that service. Thus if an application determines that an interface is supported, it will then know how to use that interface. A service is capable of providing additional interfaces that augment the standard set.

Because service providers must provide all of the functionality for an interface, interfaces are broken down by functionality. Thus, if an OLE DB service provider provides the capability to read data from its DBMS but not to write to it, an application can discover this by querying the server for the existence of the appropriate interfaces.

The core object model for OLE DB can be broken into the following four objects:

• Data Source Object— The data source object is the initial object generated when instance is defined for a given OLE DB data provider's unique class identifier (CLSID). It encapsulates much of the functionality of the ODBC environment including connection and informational properties.

• Session Object— The session object defines the scope for a transaction and generates the rowsets from the data source. This object also supports interfaces for describing schema information. The session also encapsulates the functionality of the ODBC connection for which multiple connections can exist.

• Command Object— The command object is generated from a session object. It can be used for issuing commands against the OLE DB provider, such as SQL statements. These statements can be defined, prepared, and executed. There can be multiple commands for a single session.

• Rowset Object— The rowset object is a shared data object used for returning data, such as a result set returned by executing a query. The rowset object is the minimal interface that providers must support. Rowsets are used for returning results from schema functions and command functions. There might be multiple rowsets associated with a single session or command.

There are other objects defined for OLE DB such as:

• Enumerator Object— This object provides a list of available data sources.

• Transaction Object— This object supports various transaction capabilities.

• Error Object— This object gives access to error code and messages during processing. This is similar to the ODBC function SQLGetDiagRec().

The IBM OLE DB Provider for DB2 complies with version 2.5 of the Microsoft OLE DB specification. IBM supports level 0 of the specification with some additional level 1 interfaces. The most widespread application type that makes use of OLE DD drivers is ADO-based interfaces. Microsoft supplies the ADO class library for Visual C++ and Visual Basic. Microsoft also supplies an OLE DB provider for ODBC. This provider is a bridge from OLE DB to ODBC. To connect to DB using IBM's provider within ADO, the application would perform the following:

Dim db As ADODB.Connection
Set db = New ADODB.Connection
Db.Provider = "IBMDADB2"
Db.CursorLocation = adUseClient
...

To use the Microsoft OLE DB provider, omit the Provider method. If the provider is not explicitly stated, Microsoft becomes the default.