At 12:54 PM 27/06/2007, you wrote:

>Hi all,
>
>I'm still confused with transaction management in IBObjects. In some
>posts, they suggest using transaction component (TIB_Transaction or
>TIBOTransaction) on each form. In some other posts, just used one
>(usually put in datamodule). Others suggest one transaction for DML,
>others suggest one for SELECT and one for INSERT and UPDATE. Which one
>is better? What kind of problem that might occur?

There is no simple answer to this question - it always comes down to
your actual needs, load, environment, etc. IBO provides the means to
manage multiple transactions when you need them.

An example of need could be an application that gives the user the
ability to both update tables and produce reports. You don't want
such operations to be happening inside the same transaction. Your
reports need their own snapshot transaction (Isolation tiConcurrency)
in Read_only mode (Readonly=True), while your updating operations can
carry on in their own transaction "space" - perhaps another
tiConcurrency transaction or a tiReadCommitted transaction for some
things - and a Read_write mode (Readonly=False, the default).

A technique that a lot of people use to get past the problem of
long-running transactions commanding SELECTs and causing garbage to
build up faster than the server's garbage collection can cope, is to
place the SELECTs in a Read Only, Read Committed transaction (which
can stay open all day and the dataset be refreshed as often as
required). Then, instead of using the DML methods of this dataset
for inserts, updates and deletes, the application fires off DML
statements on demand, via a TIB_DSQL object in a separate, read_write
transaction. This technique can work very efficiently with IBO -
more so than with other Delphi interface layers - if you make use of
DML Caching to keep the sets in synch.

These are just a couple of scenarios where there is benefit from
operating multiple transactions inside an application. There are
many more, that one tends to discover while seeking a way to achieve
a certain thing that you couldn't achieve before with other Delphi
components, using the "classic" TDataset model with its traditional
Edit, Insert and Delete methods.

Helen