At 05:06 AM 10/07/2003 +0000, you wrote:

>Are you familiar with the IBX.
>
>for example the query.transaction.commitretianing could only commit
>for the query only ... I have as this and Jason reply me that its
>counter part is savepoint. And when I went to the IBO help for the
>definition of savepoint its like is not what I need. Thanks for your
>clear explanation of the savepoint ... Does IBO has counter part on
>what I have mention IBX can do? without creating another transaction
>exlusively for that query?

OK, now, we have the word "savepoint" being used for two different concepts.

-- The one I responded to you about was the "savepoint" feature of
transactions, introduced to Firebird at 1.5.

-- What *you* apparently are talking about is the Savepoint method, right?

In IBO, the Savepoint method is comparable with what IBX does, in that it
posts work that is ready to post, without requiring all datasets to
post. Under the hood it is dissimilar to IBX which, as I understand, uses
a method of this name with its TClientDataset provider class (TIBSQL, or
something like that) - that posts portions of a dataset cache and can
"unpost" them using a rollbackretaining mechanism.

Rollbackretaining is available in IBO but, like Commitretaining, it is
transaction-wide in scope.

The latest test patch supports the Firebird 1.5 change by adding the
capability to name a Savepoint, and adds a LosePoint method, too. You
could visualise this as the "undo" mechanism corresponding to the Savepoint
"do" mechanism.

All this is possible in IBO, because IBO's native architecture recognises
and manages both the logical and the physical aspects of
transactions. That is the fundamental difference between native IBO and
the TDataset derivatives like IBX, FIBPlus and the various Db components in
the VCL.

IBO's transaction-aware architecture means it doesn't have any need to
compromise transaction integrity by moving datasets out to a cache. For
IBX, caching is the only way it has to manage the beginning-middle-end
logical phasing of a user task (after a fashion).

Dataset caching is not very nice because it is unsympathetic to the way IB
and Firebird are meant to work - it detaches client/server datasets from
the dynamic state of the database and forces them to behave like ISAM
tables during the period when the user is working with them. About its
only advantage is that developers who are dumb about how transactions work
can choose to stay being dumb about it. Staying dumb = less challenge to
the brain = easier = better. To these guys, it doesn't matter if a bunch
of lock conflicts at ApplyUpdates time causes the user to lose a pile of
work. These guys have different priorities.

Helen