Helen,

>>He didn't even tell what the problem is and you have identified
>>the source already! :-)

HB> Um, Nando, where have you been?

been busy reviewing papers lately. :-)

HB> This guy has been posting about increasing
HB> memory usage that doesn't get cured except by shutting down the server. It
HB> would have been easier *for you* if he had kept it in the same thread, though.

Probably. :-)

>>AFAIR the BDE doesn't even know what commit retaining is unless you set
>>special driver flags.

HB> Uh-oh, Nando, Commit Retaining was *invented* for the BDE.

Yes, to work around the problem of closed cursors on commit that had
to be reopened and refetched. A suboptimal solution, as I'm sure you
agree. But the BDE doesn't use it by default.

HB> The InterBase
HB> drivers default to it unless you use
HB> Database1.StartTransaction and
HB> Database1.Commit.

Just tested. It doesn't. It needs DRIVER FLAGS set to 4096 or 4608.
From the bdereadme:

2.2 InterBase Changes
---------------------
2.2.1 Transaction Isolation Levels & InterBase
----------------------------------------------
By adding 4096 to the setting of DRIVER FLAGS in the
Borland Database Engine (BDE) configuration, you can
specify that the InterBase SQL Links driver should use soft
commits. Soft commits are a feature of InterBase that let
the driver retain the cursor when committing changes. Soft
commits improve performance on updates to large sets of
data. When not used, the BDE must re-fetch all the records,
even for a single record change. With soft commit the
cursor is retained, and a re-fetch is not needed. Soft
commits are never used in explicit transactions started by
BDE client applications. The soft commit property
corresponds to the COMMIT RETAINING transaction option in
the InterBase documentation.

DRIVER FLAGS Isolation level Commit type
------------ --------------- ------------
0 Read committed hard commit
512 Repeatable read hard commit
4096 Read committed soft commit
4608 Repeatable read soft commit

The 4096 driver flag bit only affects implicit transaction
behavior. Use the COMMIT RETAINING property to control the
default commit behavior of explicit transactions.

Now, regardless of the default settings, is the OP using "hard
commits" or "soft commits"? The memory increase on the server suggests
soft commits, but the memory should go down when the client
application is closed.

>>And, the Paradox engine does support transactions. :-)

HB> No, the Paradox engine does not support transactions.

It does but it is limited to 256 locks, which translate to 256 records
you can touch, at most, in each transaction.

HB> *Delphi*

If you have an old copy of Paradox you can install it onto a
Delphi-clean machine and see for yourself (and yes, it uses the lck
file to do that). Not that this is of any interest to anyone here. :-)

HB> The BDE became a dead end for IB/Firebird after IB 5.6. It never was a hot
HB> option for transactional databases, since it purposely hid parallel
HB> transactions from the developer. Neither, because of those infernal lock
HB> files, was it ever a hot option for multi-client setups.

Yep. I just said that very few connectivity tools (and about NONE of
the DBMSs I know, including Oracle, MS SQL Server and IMB DB2) support
parallel non-nested transactions. The latter of your points, not much
is the former, is what makes BDE horrible with Fb. This is MHO. Those
above, however, are facts. :-)

Ciao
--
Nando Dessena
http://www.flamerobin.org