Overview

IbOleDb is an OLE DB provider for InterBase SQL Server. It was originally designed for use with ADO and MSDataShape. It can obviously be used by native OLE DB consumers, but the implemented interfaces were chosen to surface key functionality through ADO.

The IbOleDb Rowset object is the owner of the InterBase cursor. InterBase only supports one cursor per statement, so the InterBase statement handle is passed to the Rowset object during rowset creation and passed back to the Command object when the Rowset is released. If multiple simultanious Rowset objects are created by a single Command object then multiple InterBase statements are created, prepared and executed. The first released Rowset will hand its statement handle back to the Command object. The subsequent Rowset objects will have their statement handle discarded when they are released.

Since an InterBase cursor is pretty primitave, the IbOleDb Rowset object is not as feature rich as some other provider implementations. An IbOleDb Rowset is a forward-only, ready-only implementation. For IbOleDb to implement IRowsetScroll or IRowsetLocate, or even just bookmarks it would require caching the entire result set on the client. I choose not to do this for two reasons.

First, it seems like a lot of work to implement features that I'd then have to discourage consumers from using for performance and scalability reasons.

Second, the Micosoft Data Access Components already have a Rowset implementation designed to give minimally compliant OLE DB providers lots of extra functionality. Of couse it has to cache the entire result set to do it. Just choose an ADO client cursor, and you get all the fancy interfaces that the Visual Basic visual data controls require.

The IbOleDb Command object is the owner of the InterBase statement. InterBase supports multiple statements per transaction, so IbOleDb supports multiple Command objects per Session object.

The IbOleDb Session object is the owner of the InterBase tansaction. InterBase supports multiple transactions per connection, so IbOleDb supports multiple Session objects per Data Source Object.

The IbOleDb Data Source Object is the owner of the InterBase connection.

ADO Details

I am a firm believer that OLE DB is the best factored, best designed universal data access model in the world. Unfortunately, the hardships of COM programming make it unwieldly for many. All the QI, AddRef and Release of interfaces makes most people cringe when they see all the all the code it takes just to get some data to the consumer. ADO exists to simplify OLE DB programming. ADO can be used from C++, but then you get tired of all the VariantExchangeType stuff. So ADO is really attractive to VB programmers.

The three main ADO objects we'll discuss are the Connection, Command and Recordset. Thereare some others we might mention, but these map most directly to OLE DB objects and their functionality can be limited by the conformance of the provider.

ADODB.Connection

ADO packages the OLE DB Data Source Object and Session object together in an ADODB.Connection. To make an ADO connection, you really just need to know what properties to set on the OLE DB provider to allow it to connect to the database. See the Data Source Object properties.

ADODB.Command

ADODB.Recordset

OLE DB Details

Data Source Object

Implemented Interfaces

Data Source Information Properties

Data Source Initialization Properties

Session

Implemented Interfaces

Session Properties

Command

Implemented Interfaces

Rowset Properties

Rowset

Implemented Interfaces

Future Work Items

Implement IDBSchemaRowset

TABLES

COLUMNS

PROVIDER_TYPES

Implement IColumnRowset