At 02:40 AM 3/05/2006, you wrote:

>--- 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.

That's quite correct - the BDE encapsulates one transaction into the
connection context (that's your TDatabase). Its normal behaviour is
to start this transaction whenever it is needed and to roll the
commit into the row-level Post method. This is known as Autocommit
and its purpose is to make an IB/FB set behave like a Paradox or
Access table. The serious downside of Autocommit is that, when it is
used as the only way work is ever committed - the typical Pdx to
IB/FB conversion scenario - it stops the garbage collection that is
supposed to go on in the database.

So - let's be clear - the TDatabase provides StartTransaction and
Commit/Rollback methods so that you can operate explicitly on this
one-and-only-one transaction.

However, it denies you the ability to run multiple transactions
concurrently - the ability to be running, for example, a read-only,
tiCommitted transaction containing stable values like lookups side by
side with a short-running read-write transaction for performing DML requests.

>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.

The only way you could achieve that would be if you had multiple
TDatabases (connections) in a single session. With a single
TDatabase, you do not have this ability.

>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 don't know what you know. :-) But if you think you have been
running multiple concurrent transactions out of one TDatabase, you
have been deceiving yourself.

>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.

Presumably you are using Dialect 1 databases? And your needs are
sufficiently undemanding not to be bothered by the density of the
data access layering or the fragility of the Paradox layer as the
count of concurrent users rises...

It's nice that you're happy that the BDE can fulfil your
requirements...but have you considered why it has been a priority for
so long (~10 years) for third-party developers to make non-BDE
alternatives for InterBase connectivity? IB Objects began with the
Delphi 2 betas (1995) and FreeIBComponents not long after. Both have
remained under constant development, with FreeIB forking in 1998 to
become IBX and then forking again in 2001 to become FreeIBPlus.

These efforts were never vicarious: they strove always to provide
cleaner, thinner, more direct (= faster, robust) data access
layering and to implement the full IB/Fb capabilities, precisely
*because* the gap between the BDE starting blocks and the brick wall
is so narrow.

./heLen