> I missed IBX, but understand that that is
> only just starting to address transactions correctly.

They aren't "starting" to address them correctly now. They chose to
implement them differently than I did. Their model is simply raw transaction
handles and my model is a level of flexibility above the raw layer. Some
people would claim I have done them wrong and IBX did it right.

To some, they wanted to get away from the "pampered" mode of working with
transactions in the BDE and get to the raw layer. These people actually like
working with IBX transactions. With IBO you get the best of both the BDE and
IBX because you have control from top to bottom.

With IBX you have to do a lot more work to ensure that you are using
transactions properly that you don't have to worry about when using IBO.
That's where the main difference is at.

For example, in order to close a transaction all of your datasets have to be
closed too. Either that or you have to move the dataset into a
TClientDataset so that it is in an independent container. This is because a
transaction is required to maintain an open cursor and to close it closes
all cursors. IBX's architecture does not have the sophistication to release
a transaction handle transparently, let alone know when it can. As a result
you are forced to close datasets.

With IBO, it is possible to configure things such that transaction handles
can be transparently cycled keeping the OAT moving along in a healthy
manner. All of this is possible without negatively impacting your
application. (Some configuration may be desirable when dealing with huge
datasets.)

As for me, I much prefer working with IBO simply because it provides more
control and more flexibility both. These are two things that I think should
be important to every programmer... Especially where something as important
as transactions is involved.

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