(b) Run-time Access

Most new, InterBase-specific features are surfaced in the data access objects as writeable properties. Client event handling through introduced published events is adequate for most needs.

(c) Encapsulated behavior

IBX adds behaviour to enable handling of multiple transactions, multiple connections, transaction isolation/concurrency and commit options. There do not appear to be any classes, internal code or surfaced properties to support multi-threading of transactions or ISAPI-style isolation.

3.3 Controls

IBX dataset components work with all native Delphi 5 data-aware controls and the Infopower(TM) controls. No InterBase-specific controls have been added.

3.4 Performance (IBX vs BDE)

At present, no results are available for tests involving production-quality data in networked environments or involving any of the processes that would be typical of a production-capable client application.

The following results were produced from a performance bench originally written by Ravi Kumar to compare the "raw" performance of IBX and the BDE. It ran over tables of 50,000 records, each having two or three columns.

The most dramatic advantage was on query inserts - IBQuery 720%, IBDataset 1000%, IBSQL 2100% speed improvement.

Open/close table 10 times: Queries 23% faster, IBTable 2.25 times slower than TTable.

Table scans, 50,000 rows:

First to last, natural scan: IBQuery and IBDataset 33% faster, IBSQL 53% faster; IBTable 24% faster than TTable.

First to last, indexed scan: IBQuery and IBDataset 43% faster, IBSQL 60% faster; IBTable 49% faster than TTable.

Last to first, natural scan: queries 23% faster, tables 14% faster.

Last to first, indexed table: queries 24% faster, tables 39% faster.

IBX compared poorly on table locates - IBTable was 9 times slower than BDE, doing slightly worse on indexed locates than unindexed.

IBTable indexed random edit was 12% slower than either a BDE indexed random edit or an IBX unindexed random edit.

IBTable insert nearly three times slower than TTable.

IBX was three times faster executing a Stored Procedure.

It was eight times faster on Blob select and 12 times faster on Blob Insert.

3.5 Converting a BDE Application to IBX

3.5.1 Converting a BDE-based client/server application may be a painstaking transition. Jeff Overcash reported that it took him and John Kaster (Inprise Developer Relations, now Borland Developer Relations) 10 days to recode the Code Central application in IBX.

A good understanding of working with transactions is necessary, as dependency on implicit transaction handling will be a significant area of rework. The BDE's TDatabase shields the developer from physical transaction issues. IBX implements a less sophisticated architecture which requires explicit attention to coding details formerly hidden by TDatabase.

Substantial reworking will be required if the existing application used live queries or TTables, because of transaction issues and virtual ancestor methods which have not been implemented or have been implemented only partly.

The use of TClientDataset, linked to a TIB dataset as provider, has been widely recommended as a means to recoup some of the deprecated functionality or to solve problems related to unfinished functionality.

Controls should work; there will be some unexpected behavior in grids which will require extra code to restore to normal; existing filters will need to be reworked (see below).

3.5.2 BDE apps that relied on TTables will be painful to convert. Performance will be disappointing. Their use is not recommended.

3.5.3 Applications that used filtering and/or SetRange will require substantial extra work. TIBTable filtering does not implement FilterOptions nor integrate with the FindFirst, FindNext, FindPrior and FindLast methods of filtered sets. Other datasets do not support in-memory filtering except through requerying the database. IBX replaces it with IBSQL objects, exposed as SelectSQL in IBDataset and through a TIBUPdateSQL for TIBQuery. These objects will require run-time handlers in order to parse filter parameter inputs and apply the SelectSQL.

3.5.4 Implementation in the IDE and naming standards for new attributes and methods are generally consistent with those to which users of the native data access components are accustomed.

3.5.5 On-line documentation is very sparse, with inaccuracies and gaps, possibly occurring because of changes since the help was written. Help has been improved since the paper was written. A set of conversion guidelines appears to be urgently needed to highlight the "gotchas" of conversion. The changes required for implementing a database connection are not immediately obvious, for example. Users of the components may get some help from the Developer's Guide included in the beta documentation for IB 6.x.

3.5.6 The supplied demo application is viewed as a very poor sample of client/server and multi-user programming and does not use the client/server capabilities of the components at all. Bugs have been reported. Jeff Overcash has promised new demo applications.
Jeff has a couple of demo applications available on his page on CodeCentral (http://codecentral.borland.com/codecentral/ccweb.exe/author?authorid=102)

3.5.7 Developers who approach the conversion to IBX simultaneously with scaling up to InterBase from a desktop database can expect to encounter a lot of problems if they do not first get fully in touch with the significant differences between the desktop and client/server application models. An interim transition via TIBTable will probably be more useful in this situation, to help them up the learning curve; but developers should not hold their breath for a dramatic improvement in performance!

3.6 Significant Features

3.6.1. The IBX dataset classes are founded on the native Delphi TDataset, maintaining compatibility with native and third-party data-aware controls.

3.7 Licensing

Borland owns IBX. Source code for the beta version is freely available under the terms of the InterBase Public License. No deployment licensing applies.

3.8 Version Support

At time of writing (4 July 2000) the current IBX version was Beta release 4.1 of 5 May 2000.
The version current February/March 2001 is 4.51 and shipped with Delphi 6 for Linux. Upgrades can be downloaded from Jeff Overcash's download page at CodeCentral. (Registration and login required).

IBX data access components are for use with

• Delphi 5 and higher (Professional and Enterprise versions only)
• Borland C++ Builder 5 and higher (Professional and Enterprise versions)
• InterBase versions 5.x and higher.
• The Services components (not discussed here) support only the InterBase 6 Services API.

3.9 Delphi for Linux (CLX components)

Not known.

Contents

4. InterBase Objects

4.1 Background

Jason Wharton, author of InterBase Objects, discovered InterBase in the course of an exploration of client/server database products for a huge Point-of-Sale system. Against his recommendation for InterBase, the company chose MSSQL Server 6.5. Jason sought out an employer which used InterBase and Delphi and moved on.

4.1.1 TIB_ - the Native IBO Components

Not long after the release of Delphi 2, Jason discovered that the best capabilities of InterBase were virtually inaccessible to the RAD developer because of the constraints imposed by the BDE. In 1996 he determined to start his own suite of components and data-aware GUI controls to bypass the BDE and work directly with the InterBase API. He chose to develop a data access hierarchy that was independent of the TDataset and the standard Delphi data-aware visual controls, thus affording himself the opportunity to design a library of components and visual controls specifically for the client/server architecture, which could be fully customized through succeeding releases of InterBase.

4.1.2 TDataset-Based Components

Once Delphi 3 came out with the new TDataset virtual class, Jason was able to embrace the best of both worlds. He put a thin layer around his IB Objects-native dataset and brought a BDE-free InterBase TDataset-compatible component suite to life.

At that point, he was faced with deciding whether to continue making components based on his IBO datasets, already quite advanced, or to turn his focus to the new TDataset opportunity. Seeing that both would be relevant to a variety of development requirements, he decided to continue developing both strains of components. Today, IB Objects offers the developer both the simpler TIBO (TDataset) strain and the richer, more encompassing TIB_Dataset architecture.

When the simplest IBO TDataset descendant went into production in Gimbal's Marathon 1.1, it was cynically assumed by some that the final target had been met. However, after two years' more growth, the TIBO strain today covers the TDataset niche handsomely, includes custom classes to enable developers to make their own descendant classes and sits on top of a stable architecture, well-tested in heavyweight commercial environments.

4.1.3 IB Objects and Inprise

At times people have wanted Inprise to acquire IBO. Negotiations were tinkered with, off and on, but Jason was concerned that a corporate development environment could inhibit the growth he envisaged for the components and lead to shortcuts and deficiencies in the product. He has continued to progress IBO under his own auspices, to keep the development in touch with and responsive to his developer community.

4.1.4 Community Involvement and Support

During more than three years of development and three (soon to be four) full production releases, IBO source code has been open to its user community. The result is huge user involvement in its evolution and a panel of supporting coders who know the code just about as well as its author does. Daily support for both commercial and "free" users (see the Licensing topic, below) is provided by means of a fully-monitored, public list server.

4.2 How IB Objects Implements the Connectivity with InterBase

IB Objects implements the connectivity in two distinct approaches, both available whether using the TDataset-compatible strain or the fully native IBO components.

• The first parallels the native BDE strategy of TDatabase, in which a single transaction is embedded with a single connection.

• The second approach fully utilizes the elementally-separated, native IBO architecture which supports multiple transactions, threaded processing, two-phase commit and multiple connections.

4.2.1 The "TIBO" Strain - The TDataset-Compatible Components

IBO's set of "BDE-equivalent" components - referred to here as the "TIBO strain" because of its class prefix - preserves full code compatibility with controls and components that rely on the BDE's TDataset.

The TIBO components provide some enhanced functionality inherited from the IBO native data access objects that affects underlying behavior, enhancing performance and case insensitivity support while retaining the exact intention of the developer's interface code.

In the BDE, the embedded transaction's internals are hidden and cannot be accessed except through properties published by TDatabase. However, because the TIBODatabase inherits its transaction architecture from TIB_Database, its internal transaction is the same TIB_Transaction that is used elementally by the fully-powered TIB_ strain. Its full range of properties and methods is exposed at both design time and run-time. It is also possible to drop down additional TIB_Transaction components and define additional explicit transaction contexts.

The TIBO strain is often used as an aid to "soft" transition from the BDE to IB Objects. Although an eventual full transition to the full capabilities of InterBase client development is the course many developers wish to take, it is perfectly feasible to use the TIBO strain as an easy replacement for the BDE in an existing application, to enhance performance, stability and server-side capability.

Developers maintaining a BDE-based application code base designed to work with different databases can easily generate an optimal, IBO-based version for InterBase by preparing quick conversion templates for global search and replace of units and class names.

4.2.2 The "TIB-" Strain - Native IBO Components

The second "full-powered" approach removes TDataset compatibility entirely from the architecture and enables complete implementation of the transactional, server-centric and multi-database capabilities of InterBase.

It integrates tightly with a large suite of visual controls to facilitate rapid development and standardized behavior for the client/server interface. See Section 4.4, Controls.

Unless otherwise stated, the following descriptions apply to both strains.

4.2.3 TIB_Connection and TIB_Transaction Replace TDatabase

TIB_Connection obtains a persistent connection to an InterBase database and wraps all of the API functions associated with connections, as well as some some server admin functions. It can deduce protocol from the server and path properties and automatically update connection strings when one of these properties changes. The developer can access any server parameters independently, through property lists, at both design and run-time.

Login support can use custom settings for roles and user names, whether implemented with the standard login dialog or with a custom dialog. The dialogs have properties and methods to limit login attempts and to respond to illegal login attempts.

TIB_Connection has properties for setting the data display and case-sensitivity attributes for domains that will apply globally for the connection; and resolves the behaviour of columns which the application is to treat as Boolean.

It keeps a local Schema cache and has methods for flushing and renewing it when metadata change. It can also use an alternative file for messages.

It has notification methods for a large number of objects and processes, including the synchronization of datasets after external DML changes.

The dbHandleShared property allows sharing a single connection with BDE based components. Thus IBO can augment applications which need to remain BDE based, by enabling additional concurrent transactions, including cross-database transactions, involving the connection being used by the BDE.

IBO uses a model in which a logical transaction (unit of work) can involve zero to many physical transactions in its context. TIB_Transaction provides all properties, methods and events necessary to have very fine-grained control over the capabilities and interactions of physical transactions.

The interactions of transactions, in the single connection context, are managed by the IB_Connection object. The TIB_Session object allows "super-management" of the interactions of multiple connection contexts through its own properties and methods in conjunction with a TIB_SessionProps object.

IBO automates features to monitor and, if necessary, shut down long-running transactions according to configurations set at both connection and transaction levels. This process is referred to as "OAT (Oldest Active Transaction) Management".

TIB_Database (TIBODatabase for a TDataset-compatible connection) emulates the model of the native Delphi TDatabase without imposing TDatabase's restriction of limiting all connected statements and datasets to use its own internally defined transaction. The IBO database classes allow multiple transactions to be assigned to their connection context.

It was implemented to make BDE-to-IBO transition simple and fast and provide an initial BDE-free application that fully emulates the original without needing to change any application code.

The database component can be regarded as a staging-point toward a more complete implementation of the InterBase functionality. It is also useful for those who want to maintain a single code base for an application across different database systems. They can develop using the BDE to work with the other databases and use the quick convert templates to generate an IBO-based, BDE-free version for InterBase.

4.2.4 (a) Two-Phase Commit

TIB_Transaction has an array property, Connections[], to store a reference to each individual connection. The methods AddConnection() and RemoveConnection() are available for assigning and releasing connections. A ConnectionCount property is provided for enumerating the array.

The component exposes three prioritized IB_Connection properties to simplify management of the most common multi-connection scenarios.

4.2.4 (b) BLR

BLR can be used from an IBO client application.

4.2.5 Dynamic SQL

(a) Dataset components

All dataset components descend from one of two base classes - TIBODataset or TIB_Statement - which handle all of the necessary API calls to allocate, prepare and execute an InterBase DSQL statement. These base classes also interpret and define memory buffers that are bound to column objects for both input and output handling.

The TIBO strain dataset classes (TIBOTable and TIBOQuery) are TDataset descendants wrapped by an internal TIB_BDataset (bi-directional dataset). Thus, they have all of the TDataset functionality with much of it re-implemented and enhanced by transparent calls to the properties and methods of the internal native IBO object.

TIBODataset supports the assignment of a query plan, which can be either assigned in the SQL statement or patched in during the OnPrepareSQL event.

The Fields array provides pointers to a large number of other arrays surfacing properties for setting virtually every attribute that a column value can have in code and in the GUI, including display masks, Boolean behavior, labels, case-insensitive and validation masks, field trimming rules, alignment, et al.

Statement-level and dataset-level properties provide for the storing of design-time or runtime inputs to the SQL parser routines which support the complex system of buffer and index management underlying IBO's "smart" searching, locating, updating, lookup and refreshing.

This system causes virtually any dataset - including sets returned from JOINs - to behave as "live" without the addition of any handler code. Update handling for exceptional update situations is also encapsulated and surfaced as design-time or runtime properties, rather than requiring handler code.

The TIB_Dataset base class inherits from TIB_Statement and has three groups of offspring to encapsulate queries which return rows: TIB_BDataset (the internal base class for the buffered dataset classes, including TIB_Query), TIB_Cursor (and its offspring) and TIB_StoredProc.

The TIB_DSQL class, which implements TIB_Statement directly, is used for all DSQL statements that do not output multiple rows - "executable" stored procedures, batched updates or inserts, performing DDL or DML statements, et al.

(b) Selecting Sets of Data

TIBO datasets implement SetRange and smart filtering for both queries and tables, with correct resulting behavior in other dataset capabilities, including key-dependent methods such as FindKey(), FindNext(), etc. and master-detail dependency.

Select SQL can be very broadly defined at design time, i.e. 'SELECT FIELD1, FIELD2, ... FROM ATABLE' because selection and ordering criteria can be defined with very fine granularity in other design/runtime properties. Although exact criteria definition through the SQL string alone, or with Delphi parameters, is available, use of the extra properties causes the parsing engine to make best use of its server and I/O optimization capabilities.

(c) Updating, Inserting and Deleting

LIVE DATASETS
Most datasets (incl. many JOINed sets) can be live; custom update SQL is rarely needed but can be entered through the GUI of the dataset editor for any operation.

INSERTING
IBO datasets improve on the TQuery's behavior of "losing" inserted rows from the buffer which requires a refresh of the dataset for each insert performed, at considerable cost to performance.

With IBO's TIB_Dataset components (both queries and tables) the inserted row remains in the buffer where inserted. It is internally flagged to avoid messing up other algorithms whose behaviors depend on an assumed row ordering.

CACHED UPDATES
IBO cached updates do not use separate buffers for caching changes. Caching is handled natively in the dataset buffer caches. The cache remains available after the dataset is closed, refreshed, sorted, etc.

Updates can be applied to the database at any level from a single row through to multiple datasets.

(d) Refreshing Sets

Under the BDE, TDataset.Refresh method is not implemented for TQuery. IBO introduces implementations to refresh both tables and queries, with options to determine the state and cursor position after the refresh.

BOOKMARKS
The Bookmark property of TDataset and its descendants is an arbitrary string that identifies a record in a specific dataset and becomes unreliable once the dataset is closed. For the same reasons, it cannot be used to synchronize with another dataset that returns the same data. Code and variables must be implemented to overcome these limitations.

IBO implements a Bookmark that can be configured for format and content. Meaningful data, such as a primary key column, can thus be stored as persistent bookmarks which can be applied to other datasets using the same keys, or broadcast so that other datasets can respond to them and synchronize their buffers when changes are posted.

This buffer synchronization can be scoped to datasets within the same transaction context, those in other transaction contexts within the same connection context or to datasets in the applications of other users currently logged into the same database.

(e) Linking Sets

Every dataset has a KeyLinks property which defines a column or column list by which a row is distinct (unique). If it is not defined explicitly, IBO will attempt to identify it automatically from the local schema cache data. Keylinks are loaded into buffers and are referred to by many linking and parsing mechanisms.

IBO's native datasets implement linking techniques which extend beyond the simple column name matching of TDataset descendants. The developer can define several different types of set links for any dataset, including master-detail hierarchies of any depth, lookup links that are refreshed automatically and join links which are used in parsing SQL when updates or inserts are performed on JOINed sets.

Developers have access to the InterBase internal DB_KEY to guarantee that selects for subqueries and joins will always be scalar.

Other link types can be defined for user-initiated sorting of sets for searches and filtering.

A GeneratorLinks array property, implemented in all datasets, allows the developer to link a column name to a generator name, causing the generated value to be fetched into an inserted row and made available to the application.

(f) Parameters

TIB_Statement descendants all contain a Params property equivalent to that of the BDE TDataset. TDataset's Params property is directly available to the TIBO components. Additionally, various "--Links" and other properties of TIB_ datasets can be set up to assign parameters or load values into WHERE clauses by referring to columns in other datasets. It is possible to assign parameters which refer to columns not present in the dataset.

(g) Stored Procedures

TIB_StoredProc and TIBOStoredProc provide for any executable stored procedure which may or may not return a result row. Input arguments are handled automatically via the metadata, and are stored in the Params array. Results may be accessed in either the Params or the Fields array.

TIBOStoredProc is also able to emulate the Params behavior of the virtual TDataset class, storing both the input and output arguments in the Params array without losing the input parameters after execution completes.

Procedures that execute DML can (and should) be flagged to trigger resynchronization of datasets affected by the transaction.

"Selectable" stored procedures should generally be assigned to a TIBOQuery or TIB_Query, if a buffered dataset is required. An unbuffered dataset can be returned by the "native" TIB_StoredProc when a fast, unidirectional cursor is wanted.

(h) Monitoring

The TIB_SQLMonitor component can optionally trace and display all associated information for most calls to the API. If an enabled monitor instance exists, a batch of intercept API hooks is passed to the IB_Session which are, in turn, used by all of the components in IB Objects.

Statement plans and precise timings and the count of rows affected are automatically output, for immediate feedback on performance in applications.

When the intercept hooks are taken out, the application regains a direct connection to the API exports. When the monitor is not enabled, there is no performance hit and sniffing of the program API activity is impossible.

4.2.6 Client Considerations

(a) Sessions and Multi-threaded Transactions

Under most circumstances IBO handles sessions in multi-threaded apps automatically via thread local storage mechanisms.

In applications where explicit session control is required, such as an ISAPI module, IBO's TIB_Session provides the necessary isolation.

(b) Data Field Properties

IBO provides a dataset editor in which a comprehensive range of field properties and attributes can be applied within the dataset object itself, obviating the need to set them in each individual control which uses the field. It includes an SQL editor similar to that of the native VCL and facilities to fetch and display the live data before any control objects have been set down.

Property lists are provided here for setting virtually every attribute that a column value can have in code and in the GUI, including display masks, labels, case-insensitive and validation masks, field trimming rules, alignment, et al.

Boolean fields can be identified, together with their True and False values, to predetermine automatically their behavior in the application and to have them display as checkboxes when they occur in grid columns.

(Note, if a Boolean domain is defined in the database, this behavior can be set globally in the IB_Connection object.)

IBO provides full, transparent Blob handling with no limits.

InterBase ARRAY columns are fully supported, including getting and putting of slices.

GeneratorLinks, described earlier, provides linking between generator columns and their generators.

(c) Methods and Program Events

A huge number of public methods and interface events is available to surface all of the functions of the InterBase API and to support very fine-grained access to the parsing engine, callbacks, database events, navigation operations, state changes, etc.

(d) InterBase Events

The TIB_Events component replaces TIBEventAlerter from earlier Delphi versions and the IBX TIBEvents from Delphi 5, for registering interest in and responding to InterBase EVENTs. It takes care of all multi-threading issues by using synchronous event notification instead of processing the events immediately in a sub-thread.

Up to 16 events can be included; events can be registered and unregistered during run-time. An interface event handler can be added to provide custom processing of event notifications; or the component's DoEventAlert() method can be overridden to provide custom logic to the process.

(e) Searching

IBO provides a number of facilities, by way of dataset property settings, specialized controls, and smart buffering, to effect fast, case-insensitive, incremental searching on large datasets.

Grid controls have embedded navigation tools tied to certain dataset properties, for user-configured searching.

Wildcard searching is available.

QUERY-BY-EXAMPLE (QBE)
Most of the native IBO controls (checkbox, radiogroup, lookupcombo, memo, richedit, listbox, lookuplist, date, et al.) integrate with the capabilities of Search mode (dssSearch), making it possible to use the same form for entering update or record-selection data.

The controls have built-in capability to treat their contents as search criteria when the underlying dataset's state changes to dssSearch. These controls embed configurable options to change appearance when the mode changes. They are supported by a search toolbar (analogous to the TDBNavigator) with buttons for switching, ordering, saving, recalling and clearing search criteria in and out of a buffer, and for counting matching rows to the criteria entered.

Searching is optionally case insensitive per column and can be configured to work with incremental searching and nearest match enabled or disabled. It is also possible to set-up automatic SOUNDEX and METAPHONE search criteria.

(f) Dataset Navigation

Locate and keyed navigation methods are fully implemented in all datasets and integrated with the Filtered property.

See also earlier notes on Bookmarks.

Native IBO implements its own navigation bar with six button types, any of which can be invisible. All glyphs are configurable. The set includes Jump Forward and Jump Back buttons which can be configured for the number of rows per jump. There are several events to which custom handler code can be applied.

(g) Dataset Buffering

Comprehensive options are supplied for buffering datasets, accessing buffer fields and navigating. Tuning for efficient buffer performance is accomplished automatically. IBO buffers all use dynamic memory allocation and suppress whitespace.

Locate(), Lookup() and RecordCount() methods are optimized to work as efficiently as possible, using smart algorithms to minimize fetches.

All buffer methods and mechanisms, including SetRange, master-detail and filtering are integrated with global case-sensitivity settings and with one another.

Keys and whole records are allocated separately within the buffer caches. Datasets can be configured to fetch first the keys and then the remaining columns, or to fetch whole rows. The "key" approach is specifically for reducing network traffic when browsing large datasets and can be enabled or disabled as required.

The buffered datasets allow forward and reverse scrolling by any increment, multi-row selects, locates, automated "follow-me" updating of lookup fields, incremental searching, et al.

(h) Filtering

Although filters are all processed on the server, BDE filter syntax and FilterOptions are fully supported, with wildcards and case insensitivity. FindFirst(), FindNext(), etc. methods are integrated with filtering to navigate appropriately within the bounds of a filtered set.

The OnFilterRecord event can be used to filter records within the client buffers, without losing the current dataset.

(i) Dataset Cursors

TIBOQuery, TIBOTable and TIB_Query use a bi-directional cursor with a large amount of navigating capability.

TIB_Cursor uses a unidirectional cursor and is capable of very fast scans of large datasets.

(j) Using Indexes in Buffers

"Smart buffering" can determine whether to use the key buffer for searches, locates and internal operations.

4.2.7 Property Editors

(a) Treatment of properties

A full-scale dataset editor is invoked by double-clicking on any dataset component. Datasets keep arrays for many properties and the editor's interface simplifies work by allowing entry of all attributes per column or all columns per attribute. Hyperlinks permit switching between these modes.

(b) Run-time Access

All InterBase-specific features are surfaced in the data access objects as writeable properties. Comprehensive client event handling is provided through hundreds of published events and properties. IBO utilizes a local schema cache.

(c) Encapsulated behavior

IBO fully encapsulates handling of multiple transactions and multiple connections by clients configured for it, and all isolation/concurrency and commit options. "Pessimistic locking" can be enabled, which is accomplished by preceding a transaction with a dummy update. In almost all cases, live datasets are made transparent to developer and user.

4.4 Controls

Native IBO provides a full GUI development environment of more than 50 data-aware controls designed for InterBase client development. Specialized edit controls and bars encapsulate behaviours for searches and navigation, with fine control of editing and display characteristics.

Controls connect to the data access objects through the TIB_Datasource.

The 'TIBO' strain of components uses a TDatasource and connects to the native Delphi data-aware controls. This strain can use the InfoPower(TM) controls, requiring the specialized TwwIBOQuery and TwwIBOTable components for earlier Infopower versions.

'TIBO' can continue to support existing third-party report and graphing tools designed for the native Delphi VCL. Several third-party component vendors provide support for the native 'TIB_' strain of data access.

4.4 Converting a BDE Application

4.4.1 Conversion from the BDE based components to the 'TIBO' strain is a matter of performing a global search-and-replace of unit and class names. Except for one rarely-used feature of TTable, IBO implements full BDE emulation.

4.4.2 Existing settings in the BDE native Interbase driver can optionally be read at connection time to have the IBO connection duplicate the BDE configuration.

4.4.3 A detailed conversion guide is available in the on-line help, which walks through each stage of a conversion and pinpoints where differences occur. The guide explains how to test that the converted application works as it should.

4.4.4 The guide includes two practice runs that demonstrate BDE-to-IBO conversion. Both of them are fully converted in less than one minute.

4.5 Performance (IBO vs BDE)

(a) IBO employs intelligent client-side statement parsing to optimize the dialog with the server. Users who have converted production applications report excellent performance over BDE, especially on low-bandwidth connections.

(b) In performance comparisons with the BDE, IBO shows speed gains of 200 to 500 percent over the BDE on equivalent operations.

(c) Much of the client-side statement parsing for dataset operations involves shifting work to the server. Operations like Filter, Locate(), Lookup(), FindKey(), GotoKey(), RecordCount, etc. can offload whole tasks, or significant parts, to the server to minimize network I/O.

4.6 Significant Features

4.6.1 BDE-based Delphi and C++Builder applications can be fully converted and working in minutes without code changes, retaining compatibility with native Delphi and third-party data-aware controls.

4.6.2 The "IBO native" data-aware controls embed the code to utilize dataset configurations and interact with changes in dataset state, e.g. the "Query-by-Example" behavior of the specialized search controls.

4.6.3 IBO includes a number of "Tool" components for adding extra features to client applications: data pumping, running DDL scripts, table exports, et al., with encapsulated implementation support in the supplied controls, toolbars, etc.

4.6.4 Datasets are transparently "live" to both developer and user, with custom update SQL required only in rare conditions.

4.6.5 IBO ships with a comprehensive help file and many sample applications, accompanied by documentation, to demonstrate a representative range of configurations, component combinations and techniques.

4.7 Licensing

Source code and binaries are distributed under the Computer Programming Solutions Trustware License. Registered users receive full source code.

Users become registered by one or more of

(a) contributing actively to source code or documentation development

(b) developing and deploying a client application for use by a non-profit organization

(c) contributing to IB Objects source code base while using IB Objects in a fully Open Source development project, whether commercial or not

(d) paying a license fee. Unless (c) applies, the license fee is payable for any successful commercial deployment, including situations where registrations were previously granted under (a) or (b).

Managers of Open Source projects can get rights to distribute the IBO sources along with their projects if they make sure that the terms of the Trustware license are distributed and understood.

4.8 Version Support

The production release of IBO at time of writing is 3.5.

IBO components are for use with

• Delphi 2 and higher (Note, Delphi 2 upgrades will be discontinued after IBO version 3.5)
• The TDataset-compatible components must be used with a Delphi or BCB version which includes the native Delphi data access objects and data-aware controls.
• The "native IBO" components can be used with Delphi Standard versions which ship without the data access components
• Borland C++ Builder, all versions except 1.0
• InterBase versions 4.x and higher; includes full support for InterBase 6.x Dialect 3 data types, quoted reserved words as object names, and object name case-sensitivity.

4.9 Delphi for Linux (CLX components)

Under development, expected Spring 2001.

Contents

5. Summary of the Connectivity Approaches Some feature descriptions for InterBase Express (IBX) have changed as the beta development proceeded in the months following the preparation of this matrix. Please refer to the marked passages in the article for the updated information. This matrix has NOT been updated.