At 11:02 PM 26/02/2004 +0000, you wrote:

>I read the FIBPlus reveiew in Delphi Informant review by Bill Tod
>that IB7.1 no longer has problems with long running transactions. Is
>this an issue with Firebird 1.5?

Bill said:
"Using separate transactions for reading and updating the data lets you
commit changes without having the dataset closed. This works particularly
well with InterBase 7.1, because you can make the read transaction
read-committed and read-only - and that means the transaction can stay open
forever with no impact on performance."

He gives the impression that this is true only with InterBase 7.1. In
fact, it's true with all versions of InterBase and Firebird. It's a factor
of the multi-generational architecture, not some "new feature" in IB 7.1. :-)

Later, Bill says:

"The option to use separate transactions for reading and updating data is
particularly valuable with InterBase 7.1, because it lets you keep datasets
open for any length of time without worrying about performance degradation
caused by long-running transactions."

Again, nothing has changed - you always could (and should have) written
your IB/Fb applications this way - put browsing sets in a read-only,
read-committed transaction and use a separate, explicit transaction for DML
operations.

The change that IB 7.1 has (and Firebird won't have for a while) is that
you can slide in through a side-door and kill a runaway query. A runaway
query does, of course, cause a transaction to be "long-running", since the
transaction can't be committed or rolled back until the query finishes. It
really isn't pertinent to the long-running transaction problem that catches
Delphi developers.

The problem of long-running transactions arises in interfaces designed to
pick the "current row" from SELECT output set acquired via a read-write
transaction that uses CommitRetaining all day long. This is the classic
"TDataset + browsing grid" interface that Delphi makes so easy and that
created a major industry in fancy data-aware grids.

This model encourages Mr RAD Developer to implement a browsing interface
over "live" data, and use the encapsulated Insert, Delete and Edit (Update)
methods to perform work on the "current live record", without ever doing a
hard-commit. This is the source of the "long-running transactions" problem
in Delphi applications and the solution has always been there.

/heLen