Native InterBase connections from ADO and OLE DB
Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /home/project-web/iboledb/htdocs/inc/head.inc on line 13
20/Feb/2018 03:29:32 am
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.
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.
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.CommandThe ADO Command object wraps the OLE DB Command object.
OLE DB Details
Data Source Object
Data Source Information Properties
Data Source Initialization Properties
Future Work Items
©Ralph Curry 2000,
All Rights Reserved.
Logos are trademarked by their respective owners.