FAQ Help On-line Trustware License News Contributed Code
Join IBO List List Archive What is IB Objects? Downloads
Events Tech Info Sheets IBO Community Links Home
  In newsgroups and private email I'm often asked this question:
Could you comment about the advantages of using IBO instead of IBX?

I'll share a few of the advantages as I see them, without disclaiming either my personal bias or my lack of intimate knowledge of the IBX beta releases since Beta 4.2.

-- Jason Wharton

The underlying architecture of IBO is much more mature, intelligent and robust. It is now more than four years since I began developing a model to totally replace the Delphi 2 TDataset object framework with something that could be sympathetic to the way client/server and, especially, InterBase needs to work. TDataset in Delphi 1 and 2 was derived from the "small memory model" that had been so successful for Borland's 16-bit desktop databases, Paradox and dBase. It worked fine for these flat databases but compromised InterBase and other server-based databases.

I worked hard on bringing the features of server-centric processing, smart fetches into the buffers, intelligent buffer maintenance and finely controlled management of transactions forward into the client classes, rather than burying these features in the flattened-out BDE driver interface that was forced by TDataset's flat-file model.

By 1997, IBO had become a very effective, stable, industrial strength connectivity option. When Borland released Delphi 3 that year, with the virtual TDataset, it gave me the capability I needed to develop a series of TDataset-compatible components that wrapped around my native connectivity model. I have continued to grow the capabilities of these "TIBO" components up to and beyond the current version, keeping them and the native "TIB_" abreast with both Delphi and InterBase versions.

IBX uses a primitive buffering strategy which makes it quirky. It cannot refresh the buffer for one dataset without closing and reopening all datasets within the same transaction context. This can be confusing for developers and users alike because it has no smarts for repositioning the buffer cursors after refreshing. Such quirks mean a lot of sophisticated coding is needed to make IBX on its own useful for anything but very simple or low-level processes that don't require end-user interaction.

If you are writing an end-user app, use IBX as a thin wrapper to send SQL back and forth between the server and your own controls/containers. Client datasets and other in-memory datasets are recommended as containers for datasets that end-users are going to work with. Unless you are doing something like this, don't rely on IBX.

IBO was painstakingly designed to do all the work necessary to make applications behave just as one expects they should. IBO's buffering is very flexible and this, coupled with "SQL smarts", makes it possible to perform many tasks on the server instead of pulling records down and doing it on the client.

It also allows the combinations of input parameters, filters, record counts, set ranges, FindFirst, Locate(), master-detail, etc. to work harmoniously together without disabling the SQL smarts. The result is that processing can be kept on the server where it belongs, without affecting your capability to interact with the dataset's full feature set. I'm proud to believe IBO is the epitome of client-server data access architectures.

IBO is superior to IBX in the way it handles transactions. With IBX you are forced to work at the level of the "physical" transaction. There is no abstraction to allow you to work with them as explicit logical units of work as you did with the BDE. This is a huge source of confusion for people trying to learn IBX and for a good reason. The BDE provides this logical abstraction of the transaction context and handles the rest of the complexity to make it happen at the physical level. Producing applications with the BDE is much more straightforward. Unfortunately, it also introduces some undesirable behaviors at the cost of simplicity.

However, IBO offers all of the benefits that the BDE offers with regard to logical units of work and at the same time eliminates the quirks you had to deal with through having queries forced to masquerade as tables. IBO doesn't hide full control over transactions at a physical level: you can have that, too. So, IBO delivers the best of all worlds for transaction handling.

As an example of how this may affect your applications, consider this scenario. With InterBase it is VERY important that a "physical transaction" not be left open for too long. This emphasizes how important it is to make sure that transactions are being closed properly. With IBX, ending a transaction forces all open datasets to be closed. This leaves you with Hobson's choice: force datasets to be closed periodically or let users' work practices determine when transactions end and risk havoc on your server if someone happens to leave a dataset open.

As far as I am aware, IBX can't offer any other choice. To provide for anything more sophisticated, its next step would be to re-introduce the quirks that the BDE has. From there it would be a very long stretch to go the distance IBO has gone to eliminate those quirks and get it all right.

IBX requires that you do a StartTransaction before any datasets are opened. Thus, transactions are not just purely for logical processing of units of work but they actually impact whether you can even read data at all. While this is a real-world reflection of how InterBase is physically, it is very awkward for most application development purposes. It requires that all of your code needs to be written around the need to coordinate the opening and closing of all datasets with the physical transactions they belong to, instead of just focusing program logic on how changes are sent to the server and handled.

This restriction makes it an irksome task to design and write a GUI application that is comfortable for an end-user to interact with.

With IBO there is a very intelligent abstraction layer above the API that makes transactions much more friendly to work with. IBO considers three aspects of handling transactions. There is the physical level, the API (which is as far as IBX goes); there is the logical level, where units of work are defined; and, lastly, there is the explicit transaction context, which you, the developer, can choose to dictate in your application. The three aspects overlap considerably and IBO gives you full control over each of them. In your code, you can take the driver's seat and use the explicit transaction mechanisms to control things pre-emptively; or you can have your application react to the logical state of the transaction that results from what the user has been doing.

OAT (Oldest Active Transaction) HANDLING
At the physical level, many things can be done to make sure a transaction isn't going to be held open for too long. IBO activates timeout handlers at various stages which, in most cases, will handle freeing up the physical transaction handle automatically. In this way, server resources are conserved and the OAT can advance in a healthy manner.

If something is hanging things up, all of the properties are available to pinpoint what is going on and respond to it. It is really easy to set up comprehensive mechanisms to interact with the user for resolving prolonged transactions. If cached updates are in use, IBO always takes care of them without having to interrupt the user at all.

With IBX, transactions can be held up even when using cached updates, because datasets have to be opened. Recall that IBX needs you to have a physical transaction open in order to have a dataset open.

With IBO it is possible to give each dataset a specific behavior when a transaction is ended. There are a number of different behaviors to choose from.

Such options make IBO much more flexible than the BDE's approach, which is to fetch all records for any open datasets whenever a commit or rollback is performed. With IBO you are in TOTAL control of your application. All the features and behavior described here and much more about IBO transaction handling are documented in detail in the help files and sample applications.

Conversion from existing BDE based applications is exponentially easier with IBO than IBX. IBO emulates practically everything that the BDE supports. Many applications convert literally in minutes to IBO. Two sample applications come with the IBO kit, for practice runs which convert almost immediately.

IBX leaves a lot of BDE functionality unsupported and is significantly different in its implementation of some key things. That makes it necessary for the developer to do major re-work and testing before a conversion is complete. The favored components in IBX are virtually nothing like the BDE based datasets and continue to undergo major revising that affects the interface of the components.

I believe IBO's trustware licensing vehicle is more powerful than IBX's. IBO is free for everyone who is willing to contribute even the slightest help to develop, document, make samples, etc. to it. They chose IBO over IBX because it is more reliable and a much more highly finished product. Most of the typical open source recipients can request to use IBO free of charge. This includes hobbyists just trying to brush up skills, non-profit organizations, religious groups, students, approved open source projects and even developers with commercial intentions who don't yet have the funds to afford licensing. All of these people can use IBO free under the trustware licensing that I use. I don't see IBO developers being at any disadvantage to IBX with respect to licensing.

IBO developers who are using it commercially invest in IBO's continued success and development by committing a modest portion of their returned revenue to a subscription for commercial licensing. It gives them a way to ensure that it will thrive in the future because these funds go into the production of professional documentation and support materials and to fund a few employees to improve the product.

IBX has no entity with any commercial incentive to provide support materials or keep it in a predictable development cycle.

Because Trustware provides motivation for commercial users and voluntary contributors alike, I have every reason and incentive to sustain and grow IBO under this model. I do not base my revenue on service and support contracts. My own objective, to make IBO and InterBase powerful yet easy to use, does not hinder me at all. My motivation is to make IBO so nice and easy to use that people will be eager to submit trustware revenue to keep the ball rolling.

If Delphi and CPPB developers of InterBase/Firebird apps can be well informed about the suites of components they have to choose from, IBO will win in both commercial and open source segments. The purpose of Trustware is not to make anybody rich. It is to focus the IB community's effort into one strong product instead of splintering and having many weak, poorly supported products with uncertain outcomes. IBO has been around the longest and it is well proven in high-demand production environments. I am confident that it is the best possible connectivity solution for building robust, reliable client applications for InterBase/Firebird.

One of IBO's significant benefits is that its native data access architecture is built from TComponent up. This means you you can harness the full power of IBO without the TDataset architecture that Borland provides. What this means in terms of software investment is that you can use IBO with the standard version of Delphi - VERY cheap compared to the Professional and Enterprise versions.

If you have an open source project and you really want to minimize costs, use native IBO with standard Delphi or CPPB and your cost of ownership is a fraction of what it would be if it was entailed to Borland's high-end packages. If you are not using other commercial third party components, you lose nothing by doing this. Several third-party packages, such as the award-winning Report Builder and Report Printer Pro actually do support the native IBO data access architecture.

And, who knows, there may eventually be a Delphi Foundation version released for free, making it possible for open source projects to use it with IBO and incur absolutely no software purchase expenses at all. If this were to happen I believe it would ensure that IBO continued to be the component suite of choice. There would be no financial entry barrier at all.

Versions of IBO up to and including 3.x support all 32-bit Delphi versions and all versions of InterBase/Firebird. Delphi 2 enhancements will be discontinued with the forthcoming Version 4, first quarter 2001. Delphi 6 support is already in development, for both Win32 and Linux platforms.

With IBX you are required to purchase at least the Professional version of Delphi 5 or higher. The components don't work with lower versions of Delphi and, at the time of writing, CPPB support is still to be made usable. The prospects for a Linux version of IBX are undetermined.

In the InterBase world a potential fork is looming over us with Borland seeming to do their own thing and the open source community giving up hope on open cooperation and communication from them. The open source folk are impatient to forge ahead with Firebird and implement the possibilities of the "real open source database", with or without Borland.

If this happens it seems probable that choosing IBX will lock developers into choosing whatever Borland produces and thus bind their applications to an inferior, poorly supported back-end product which will not be free. If IBX fails to keep up with Firebird development, which already seems likely, choosing IBX would mean foregoing the opportunity to work with the Firebird enhancements at all. Its sole developer, Jeff Overcash, has often publicly presented himself as an opponent and detractor of the active community open source effort.

Those who choose IBO can be assured that I will do my very best to support both Firebird and Borland's products as long as possible. This way, it will be an open choice for all IBO people whether they use Firebird or Borland.

As far as I can see, Borland is not playing the open source game the way it needs to be played and so I think it should be most people's concern to keep their options open until things between these two factions resolve.

If you are sure you want to stay with Borland then IBX is an option and so is IBO. If you want to keep your options open, stay away from IBX. I highly doubt IBX will be made to work with Firebird since the only good thing going for IBX right now is that Jeff Overcash remains willing to persevere with its beta development.

Jason Wharton
27 December 2000


Architecture & Quirks
Transaction Handling
Transaction Scenarios
Transaction Aspects
O.A.T. Handling
Datasets & Ending Transactions
Converting from the BDE
Commercial Usage
Why Trustware Works
Independence & Affordability
Firebird vs Borland