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.