And I must excuse that I have not been too clear in some points.
Most of all I should have written that I am not using Delphi/Paradox,
but dBase 7. Many things are similar with, while others are different
But there's the same BDE under the hood.
> 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.
Do you know of any place where to read more about that?
Wherever I decided to not use explicit transaction control I was
screening the effects of those auto-committed transactions.
They are by default "hard"-committed and I don't see a downside on
performance or garbage collection.
But the biggest part of my conversion task is still to come, and my
job somehow is hanging on it. So, if I HAVE to explicitely control
EVERY transaction, I will do this as one of the next steps.
> 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.
Yes, in those cases where I need to, I do have several
"database"-objects for concurrent connections.
> 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...
No, after testing several DBMS for the future of our company I finally
decided for Firebird in March 2004 and that's about when 1.5 and
Dialect 3 where the thing to do.
I have about 45 concurrent users in 4 databases with a total of about
The only problem I still have is that with ZOMBIE-connections on my
But about that, finally, it was lately found out that it is not the
fault of BDE.
> It's nice that you're happy that the BDE can fulfil your
I am definitely NOT happy to be bound to a dead horse.
And, yes, most definitely the BDE became a problem once my application
was using more than some dozen tables and had more than 5-8 concurrent
The application is at the end of it's lifecycle, but I can only change
it bit by bit, because the company is depending on it every day.
I made my plan out of this scenario, only I try to keep up reading
here to not miss something vital. I just don't want to start over
again once I finished about 80% of this task.