> Could you comment about the advantages of using IBO instead of IBX?

There are a number of advantages to using IBO over IBX. I'll share a few of
them. I disclaim that I have personal biases and my knowledge of IBX could
be outdated since I don't follow it closely.

First of all, the underlying architecture of IBO is much more mature,
intelligent and robust. (How's that for a biased opinion? <g>) If you are
irritated by this statement you may not want to read on since you will
probably be enraged by the time you get to the end of this...

I realize this is quite a lengthy response. My apologies to share this in a
news group. It isn't a copy paste job I'll assure you that. I'll put headers
so you can skip parts if you like.

ARCHITECTURE AND QUIRKS:
IBX has numerous quirky behaviors with its primitive buffering strategy.
Because of this most people only use IBX for 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 fourth between
the server and your own controls/containers. Client datasets are a popular
container as are other in-memory datasets. Unless you are doing something
like this, don't rely on IBX.

IBO was painstakingly designed to do all the work necessary to avoid quirks
so that applications behave just how one expects that they should. IBO's
buffering is very flexible and is also coupled with "SQL smarts" that makes
it so that many tasks can be performed 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 all work in harmony without disabling the SQL smarts
capabilities to keep processing on the server where it belongs while you
still get to interact with the dataset's full feature set. IMNSHO, IBO is
the epitome of client-server data access architectures.

TRANSACTION HANDLING
IBO's transaction handling is much better than IBX's. With IBX you are at
the "physical transaction" level with no abstraction to work with them in a
logical sense. This is a huge point of confusion for people trying to learn
IBX and for a good reason. The BDE abstracted transactions so you worked
with them in your application as an explicit/logical unit of work. The BDE
handled the rest of the complexity to "make it so" at the physical level.
This made it much more straight forward to produce applications.
Unfortunately the BDE also introduced some undesirable behaviors in its
attempt to make these things simpler. However, IBO offers all of the
benefits that the BDE offered and at the same time has eliminated the quirks
you had to deal with. On top of that, it is still possible to have full
control over transactions at a physical level too. So, IBO delivers the best
of all worlds where transaction handling is concerned.

TRANSACTION EXAMPLE
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. So, it is important to make sure that
transactions are being closed properly. With IBX, when you end a
transaction, this forces all open datasets to be closed. Thus, you have a
choice. Force datasets closed periodically or cause havoc on your server if
a user leaves a dataset open somehow. There is no sophistication in IBX to
do anything more than this (at least that I am aware of). It's next step to
do anything more sophisticated would be to introduce the quirks that the BDE
had and from there it is a very long stretch to go the full distance IBO has
gone to do it all right.

Also, IBX requires that you do a StartTransaction before any datasets are
opened. Thus, transactions are no more purely for logical processing of
units of work but they also impact whether you can even read data at all.
This is how InterBase is physically but this is very awkward for most
application development purposes. So, all of your code needs to be written
such that all datasets are opened and closed in harmony with transactions
instead of just focusing on how changes are sent to the server and handled.
This is very irritating when trying to write a GUI application that is
comfortable for an end-user to interact with.

TRANSACTION ASPECTS
With IBO there is a very intelligent abstraction layer above the API that
makes transactions much more friendly to work with. IBO considers there to
be three aspects to handling transactions. There is the physical level,
which is the API (as far as IBX goes), and there is the logical level, which
is where units of work are defined, and last of all, there is the explicit
transaction context which is what you as a developer will dictate in your
application if you chose to. There is a lot of overlap between these three
aspects and IBO gives you full control over all of them. In your code you
can take the driver's seat and use the explicit transaction mechanisms to
control things or you can react to the logical state that the transaction is
in depending on what the user has been doing.

OAT (Oldest Active Transaction) HANDLING
With the physical level there are a lot of things that can be done to make
sure that a transaction isn't going to be held open for too long. Various
stages of timeout handlers are activated that in most cases will
automatically handle freeing up the physical transaction handle so that
server resources are conserved and the OAT can advance in a healthy manner.
If something is hanging things up all of the properties are there to
pinpoint what is going on and respond to it. It is really easy to setup
comprehensive mechanisms to interact with the user to resolve lengthy
transactions. If using cached updates then IBO will always take care of this
without having to ever interrupt the user at all. With IBX even when using
cached updates transactions can be held up because datasets are opened.
Remember that with IBX you have to have a physical transaction open in order
to have a dataset open.

DATASETS AND ENDING TRANSACTIONS
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 chose
from. You might want it to simply fetch all of the records and then remain
with that in memory. You might want it to automatically refresh such that it
will get any changes visible to the new transaction. If all of the records
have not been fetched you can simply invalidate the cursor which allows the
transaction to end and the dataset remains intact. The next time it is
accessed it recognizes that its cursor is invalid and it automatically opens
a new cursor and is transparently right where it was before with minimal
load on the server to accomplish it. You might also want it to close the
dataset (which in native IBO causes it to go into search mode). This is much
more flexible than the BDE's approach of always fetching all records for any
open datasets when a commit or rollback was performed. With IBO you are in
TOTAL control of your application. All that is said here and much more about
IBO transaction handling is documented in detail in the help files.

CONVERTING FROM THE BDE
Conversion from existing BDE based applications is magnitudes easier with
IBO than IBX. Very little of what the BDE supported is not supported with
IBO. IBX leaves a lot of things unsupported and has a significantly
different way of implementing some things that make it necessary for the
developer to do major work and testing before their conversion is complete.
Many applications convert literally in minutes to IBO. There are two
practice runs showing two applications which convert almost immediately. The
favored components in IBX are virtually nothing like the BDE based datasets
and are going to continue undergoing major revising that will affect the
interface of the components.

LICENSING
IBO's trustware licensing vehicle is IMO more powerful than IBX's. With IBO
being free for everyone who would be willing to contribute even the
slightest help to develop, document, make samples, etc. to it, they will
chose IBO over IBX because it is magnitudes better and more complete as a
product. Most all of the typical open source recipients can also use IBO for
free as well. This includes hobbyists just trying to brush up skills,
non-profit organizations, religious groups, students, open source
applications (upon approval) and even people with commercial intentions that
don't yet have the funds to afford licensing. All of these people can use
IBO for free under the trustware licensing that I use. So, this puts IBO as
favorable as IBX there too.

COMMERCIAL USAGE
With IBO those who are using it commercially that have a vested interest in
IBO's continued success and development have a way to insure that it will
thrive in the future. They have the privilege to share a modest portion of
revenue from their profits to support IBO through commercial licensing.
These funds go into the production of professional documentation to make it
easier to learn how to use IBO as well as supporting a few employees to
spend significant amounts of time dedicated to improve the product. With IBX
there is no entity with any commercial incentive to keep it thriving.

WHY TRUSTWARE?
Trustware provides ideal motivations for all concerned. I have every reason
and incentive to keep IBO thriving under this model. Since I do not base my
revenue on service and support contracts my motivations to make IBO powerful
yet easy to use do not hinder me at all. I am motivated to make IBO so nice
and easy to use that people will be eager to submit trustware revenue to
keep the ball rolling. By this strategy, if people educate themselves
properly about what suite of components they use, IBO will crush the
competition from both commercial and open source segments. The purpose here
being to keep a focused effort on all the IB community's part to combine
strength instead of splintering and having many weak products. IBO has been
around the longest and I feel the right to move forward in this way.

INDEPENDANCE AND AFFORDABILITY
Another great advantage that IBO has is its native data access architecture
is built from TComponent up. As a result, you can harness the full power of
IBO even without the TDataset based architecture that Borland provides. This
means that you can use IBO with the standard version of Delphi which is VERY
cheap compared to the Professional and Enterprise versions. Thus, if you
have an open source project and you really want to minimize costs, use
native IBO with standard Delphi and your cost of ownership is hardly a drop
in the bucket to what it would otherwise be. If you are not using other
commercial 3rd party components you lose nothing by doing this. Especially
since many actually do support the native IBO data access architecture like
Report Builder and Report Printer Pro.

With IBX you are required to purchase at least the Professional version of
Delphi. And, who knows, there may eventually be a Delphi Foundation version
released for free which actually would make it possible for open source
projects to use it and IBO and incur absolutely no expenses at all to
develop their applications. If this were to happen I believe it would insure
that IBO will continue to be the component suite of choice. There would be
no financial barrier of entry to it if this were the case.

FIREBIRD VS. BORLAND
Another advantage is right now in the InterBase world there is a potential
fork 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
Borland and just being content to forge ahead with Firebird and the "real
open source database" of choice without Borland. If this happens it seems
that choosing IBX will lock someone into choosing whatever Borland produces
and foregoing the opportunity to work with Firebird should significant
changes eventually take place.

If people chose IBO then they can be assured that I will do my very best to
support both Firebird and Borland's products as long as is feasibly
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 solidify. If you are sure you want to stay with Borland
then IBX is an option. 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
person developing it right now is seemingly anti-Firebird/pro-Borland. I
think the best thing going for IBX is that it comes out of the box and if it
were not for Jeff Overcash IBX would be dead in the water in spite of it.
How long will Jeff hold out anyway? I think we are all amazed so far.

I suppose this is enough for now. If you feel the need to flame me for these
comments, keep in mind I have already disclaimed that I have my personal
biases here and that I don't claim to have accurate information concerning
IBX. If you need to correct anything I have said, please, please do so.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com