--- In firebird-support@yahoogroups.com, Helen Borrie <helebor@...> wrote:

> It simply doesn't support the transactional
> model for multi-user concurrency. What is does in Firebird's case is
> to remove transactions from the picture entirely and create Paradox
> tables to store the output of queries. When attacked in this manner,
> Firebird *will* enforce transaction atomicity.

Helen,
of course I am by far not in a position to doubt your experiences
about databases, but maybe there's a chance that you and Adam could be
wrong about that?
Because I at least have a feeling that I have transactional control
using BDE with Firebird.

While I've done some 20% of my conversion, I will still have to use
the BDE for accessing Firebird for some time to come. Same as Leslie,
I am first converting the database, then the application and DB-layers.

I _can_ explicitely start transactions as well as TRY/CATCHing the
result and depending on the result ROLLBACK or COMMIT them.

In fact I wrote a small test-application, which I am using in
workshops to show other "old-fashioned" programmers how all this
transaction-stuff is working, and it perfectly shows the effects of
and differences between auto-transactions, explicit transactions and
rolling back or committing them.

There's nothing to complain for me. The BDE seems to be doing this job
just fine.

Contrary to the documentation, it is even possible to start several
transactions at once, and to have them running parallel in one
application/session.

If you do know something about that which until now slipped me, I
would very much like to know which traps ahead I did not notice so far.

I am of course not using the "native" INTRBAS-driver, but ODBC.
And I am aware that ODBC is not the top of the cream for a modern
application.
But it's my only way out. And it works very reliably.

ciao,
André