Subject | Re: [firebird-support] How to hard commit |
---|---|
Author | Nando Dessena |
Post date | 2005-03-08T06:43:41Z |
Helen,
H> unfortunately.
He didn't even tell what the problem is and you have identified
the source already! :-)
H> If you don't start and commit the transaction explicitly,
H> the BDE driver uses CommitRetaining to simulate the non-transactional
H> behaviour of the Paradox engine and memory resources get stuck forever,
H> until the database is in a shut down state.
AFAIR the BDE doesn't even know what commit retaining is unless you set
special driver flags. What it does is auto-commit each statement, so
the OP is safe: it might not be efficient, but it's not going to
generate garbage or other unpleasant results. And, the Paradox engine
does support transactions. :-)
H> That's one of the many reasons there are so many abstraction layers
H> available for IB and Firebird: the BDE "out-of-the-box" simply *never*
H> manages transactions properly.
From this POV it's not much worse than dbX or any other layer that
don't support parallel transactions (which include ODBC and JDBC, for
the record). Let's say it's much easy to get it wrong due to the
default autocommit behaviour.
I share you opinion that, anyway, the sooner the OP leaves BDE to its
fate, the better. :-)
Ciao
--
Nando Dessena
http://www.flamerobin.org
======================================================
I support Firebird, I am a Firebird Foundation member!
Join today at http://www.firebirdsql.org/ff/foundation
======================================================
>>I have a tdatabase with transisolation set to tiReadCommitted. Do IH> Oh dear, you are using the BDE. This is the source of your problem,
>>need to do periodic hard commits or are those done immediately?
H> unfortunately.
He didn't even tell what the problem is and you have identified
the source already! :-)
H> If you don't start and commit the transaction explicitly,
H> the BDE driver uses CommitRetaining to simulate the non-transactional
H> behaviour of the Paradox engine and memory resources get stuck forever,
H> until the database is in a shut down state.
AFAIR the BDE doesn't even know what commit retaining is unless you set
special driver flags. What it does is auto-commit each statement, so
the OP is safe: it might not be efficient, but it's not going to
generate garbage or other unpleasant results. And, the Paradox engine
does support transactions. :-)
H> That's one of the many reasons there are so many abstraction layers
H> available for IB and Firebird: the BDE "out-of-the-box" simply *never*
H> manages transactions properly.
From this POV it's not much worse than dbX or any other layer that
don't support parallel transactions (which include ODBC and JDBC, for
the record). Let's say it's much easy to get it wrong due to the
default autocommit behaviour.
I share you opinion that, anyway, the sooner the OP leaves BDE to its
fate, the better. :-)
Ciao
--
Nando Dessena
http://www.flamerobin.org
======================================================
I support Firebird, I am a Firebird Foundation member!
Join today at http://www.firebirdsql.org/ff/foundation
======================================================