Alan wrote:

> Michael wrote:
> > I manually start every transaction by doing this:
> >
> > if (not (DMEksp.trEksp.InTransAction)) then
> > DMEksp.trEksp.StartTransAction;
> >
> > Do a little or a lot.
> >
> > if ((DMEksp.trEksp.InTransaction)) then
> > DMEksp.trEksp.Commit;
> >
> > Isn't that the right way to handle transactions ?
>
> I don't always manually start a transaction.

You need to bear in mind with IBO there are three separate aspects with
Transactions that are separately managed (with some crossover).

> Opening a query will start it's transaction.

Opening a query will acquire a physical transaction automatically but this
is entirely distinct from calling the StartTransaction method.

> I often test is a transaction is started before
> I open a query or execute a cursor, if it's
> already started I try to commit and start it
> again.

This may or may not be wise depending on what else is going on in the
transaction's context.

> I've posted elsewhere here about the subtleties
> of the different methods of testing if a
> transaction is current. If you are religious
> about manually starting them, then you may
> rely on one method of testing. If you are not
> religious about manual starts (and use
> implicit transaction starts.....
> you start a transaction implicitly by opening
> a dataset. You start it explicitly by first
> starting it then opening the dataset.

An explicit transaction is only started when you as the application
programmer make a call to the StartTransaction method. If you never call
this method then InTransaction will NEVER be true. IBO only uses the
explicit transaction mechanisms internal to the applying of cached updates
when called at the transaction/database level.

The other aspects will tell you what you need to know about what is going on
with transations. They are the logical and physical aspects. Much has been
said concerning this and in order to make the best use of IBO you really
should come to terms with this information.

> the problem I have now solved has everything
> to do with this disparate way IBO handles
> these two kinds of transaction starts and which
> boolean test you use of the three:

> IB_Transaction1.TransactionIsActive

This is the logical aspect that indicates whether or not an update of some
kind has been sent to the server and is awaiting a commit or rollback.

> IB_Transaction1.Started, or

This is the physical aspect and merely tells if there is a transaction
handle present but gives no indication of whether there are any changes yet
to be committed.

> IB_Transaction1.InTransaction

This is where you as a programmer take some explicit control about how
changes are handled.

> in order to test and refresh this implicit or explicit transaction.

Please don't think of them as separate kinds of transactions being started.
The transactions are not separate. Rather, you are being given separated
control over aspects of the transaction. They are the same transaction
being managed.

> The timeout props behave quite differently
> with an implicit transaction start as
> opposed to an explicit start.

Yes, when you take it upon yourself to explicitly control transactions then
the OAT mechanisms take that into consideration.

Hope this helps,
Jason Wharton