IB Objects is the most powerful toolbox available for developing client and service applications for InterBase/Firebird in Delphi and Borland C++Builder without the BDE, ODBC or any other middleware. IB Objects provides more than 80 components for use with 32bit Delphi and C++Builder. The ""native IBO"" classes require only a Desktop Developer edition. Professional editions of these products are required only if you need to develop with the TDataset-compatible classes. Please note the comments in the right-hand sidebar regarding IBO version support for the various Delphi versions.

Why was IB Objects needed? Generic client-to-database layers like the BDE, ODBC, dbExpress and ADO hide most of the capabilities of transactional database engines, flattening connectivity to a generic ""lowest common denominator"". Powerful server databases like InterBase/Firebird and Oracle are made to conform to the behaviors of desktop databases like Paradox or dBase. It takes heavy layering of client and middleware driver code between the user and the database to accomplish this flattening, while disabling essential capabilities of the server databases' engines.

Since everything in InterBase/Firebird happens inside transactions, this approach essentially kills most of the benefits of using client/server for networking mission-critical applications. IBO cuts right through all this and connects its data access objects directly to the application programming interface (API) of the InterBase/Firebird engine. Your application gets full and complete access to InterBase transaction capabilities - multiple concurrent transactions for a single connection and transactions that span multiple databases with two-phase commit.

Four levels of concurrency isolation become available and, with them, the full, flexible range of controls that InterBase provides for optimizing transaction life and resolving lock conflicts. What about other component suites? Other component suites can provide direct-to-API connectivity but they do so at the cost of developer control over the logical aspects of transaction-based data processing. They are bitten by the hand that feeds them.

In order to implement access to the physical capabilities of the transaction engine while remaining locked into the memory dependency of the VCL's TDataset, they sacrifice the considerable benefits the BDE provided in the way of task management. Why choose IB Objects? From the start IBO freed itself from the restrictions of TDataset and its limiting, local database oriented memory model. From the primitive level of TComponent forward, its classes are built on a foundation dedicated solely to how an object interface needs to interact with InterBase/Firebird with greatest effect and efficiency. Along the way, IBO has succeeded in emulating and improving on the logical task environment provided by the BDE to the degree that a developer can choose to be unconcerned with the physical transaction altogether.