> Yes, if the CommitAction of a dataset is not caClose then it will cause

the

> transaction (physically only) to be acquired again.

Oh, I meant to add that the OAT handling will clear it up based on timings
optimized for efficiency. Not to worry.

PS. Here's what you are missing from the IBX world of transaction handling:

>>>>>>>>>>>>>>>

From: "Jeff Overcash (TeamB)" <overcash@...>
Newsgroups: borland.public.delphi.database.interbaseexpress
Sent: Friday, February 09, 2001 8:33 PM
Subject: Re: IBTransaction.Roll Back doesn't work


Here is basically the different types of logic bugs the AutoStart can cause.

Single Dataset + Single Transaction
IBDataset.Open (Auto Start Transaction)
// Do some IBDataset posts of some sort
IBTransaction.Rollback;
// Psuedo the event logic from here on out
a) Calls DoBeforeTransactionEnd
b) Tells each Dataset the transaction is closing
c) IBDataset sees that it is the last open dataset and that it started the
transaction so it closes and calls commit
d) IBTransaction.Commit will call DoBeforeTransactionEnd
e) All datasets are closed so it returns to d)
f) Commit is done and return to the IBDataset in c)
g) return to the Initial Rollback call and do a Rollback

So in a Single dataset - AutoStart situation you can not rollback, a
commit will always fire before the actual Rollback will fire.

Here are two different logic behaviors for 2 dataset's one transaction

IBDataset1.Open; file://AutoStart
IBDataset2.Open;
IBDataset2.Close;
IBDataset1.Close;

At the end of this sequence the Transaction is committed and closed. But
this ordering

IBDataset1.Open; file://AutoStart
IBDataset2.Open;
IBDataset1.Close;
IBDataset2.Close;

leaves you with an uncommitted open transaction.

All of these go away if you manually start the transaction by hand and not
let
the AutoStart mechanism go into place.

The knowledge of it begin AutoStarted should have been at the Transaction
level
all along, then it would always commit when the last Dataset set was closed
and
it was autoStarted no matter the closing order. The first example also goes
away with the logic at that level since the problem is that the Dataset is
doing
the commit, but if the logic is in the Transaction level that won't occur on
a
Rollback.

As for why it was done, I'm not certain if this was an artifact from the FIB
bases for IBX or something introduced by Ravi. I do know Ravi did not want
to
AutoStart transactions at all, but the Delphi team insisted that it work
that
way. This Rollback bug in single dataset mode was just something that got
through the D5 beta testing. I intend to get the logic in the right place
(up
at the transaction level) by D6 if not earlier. It isn't a major change
actually, but a fair amount of testing the different permutations.

Aldo Caruso wrote:

>
> Thanks a lot Jeff, it worked Ok.
> I wonder why IBExpress developers let the IBTable open the Transaction in
> such a way that the Roll Back fails ?
> Aldo
>
> --
> Jeff Overcash (TeamB)
> (Please do not email me directly unless asked. Thank You)
> The correct way to punctuate a sentence that starts: "Of course it is
> none of my business but ~" is to place a period after the word "but".
> Don't use excessive force in supplying such a moron with a period.
> Cutting his throat is only a momentary pleasure and is bound to get
> you talked about. (RAH)

>>>>>>>>>>>>>>>

They are going to have to really mix things up to get them right. Jeff has
no idea just how screwed up their transaction model is, or perhaps he does.
It does seem he is catching on here. I pity him for the mess he has to clean
up.

I also find his taste in quotes horridly detestable.

FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com

----- Original Message -----
From: "Jason Wharton" <jwharton@...>
To: <IBObjects@yahoogroups.com>
Sent: Monday, February 12, 2001 7:10 PM
Subject: Re: [IBO] IB_Query.CommitAction


>
> If you want to force a transaction closed simply call it's Close method.
If
> AutoCommit is true it will perform a Commit of not it will perform a
> Rollback. Calling CloseWithConfirm will prompt to Close the query and
> EndWithConfirm will prompt and allow the Dataset's CommitAction to take
> place.
>
> It's all been thought of already, I just got to get people in the habit of
> asking about it...
>
> Actually, I just need to document it all.... <g>
>
> FWIW,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
> ----- Original Message -----
> From: <guido.klapperich@...>
> To: <IBObjects@yahoogroups.com>
> Sent: Monday, February 12, 2001 7:08 PM
> Subject: Re: [IBO] IB_Query.CommitAction
>
>
> > Let me see, if I understood it the right way:
> > caClose: Closes the Query
> > caRefresh: Refreshes the Query after commit. But will this not start the
> > transaction again ?
> > caFetchAll: Sorry, no idea
> > caInvalidateCursor: In short words, all stays as it is. The Query keeps
> open,
> > but the Transaction is closed.
> >
> >
> > Guido
> >
> > Jason Wharton wrote:
> >
> > > They are self explanatory. When the transaction commits that is the
> action
> > > the datasets do. perhaps the only one that isn't totally clear is
> > > caInvalidateCursor. What that is intended to do is try to preserve as
> much
> > > of the existing situation as possible without imposing extra work. If
> the
> > > dataset has fetched part way through the dataset it won't fetch any
more
> > > records and it won't refresh until it is accessed again.
> > >
> > > HTH.
> > > Jason Wharton
> > > CPS - Mesa AZ
> > > http://www.ibobjects.com
> > >
> > > ----- Original Message -----
> > > From: <guido.klapperich@...>
> > > To: "ibobjects@egroups.com" <IBObjects@yahoogroups.com>
> > > Sent: Monday, February 12, 2001 6:38 PM
> > > Subject: [IBO] IB_Query.CommitAction
> > >
> > > > Can anybody explain me the different values of the
> > > > IB_Query.CommitAction-Property ? The OH says nothing about it.
> > > >
> > > >
> > > >
> > > > Guido.
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> >
> >
> >
> >
> >
>
>
>
>
>