Hi, my name's Arnaldo and I worte from Brasil.

I don't like use manuals tranasaction, becouse, some times I fogot to
do that.

I've use the properties of TIBQuery, REQUESTLIVE with TRUE, and that
component, manager transaction to me, all moment I use POST method
auto start a TRANSACTION and COMMIT.

I use methods INSERT and EDIT how I do with TTable component.

By example:
iboQryCountry.Insert or iboQryCountry.Edit

and apply updates with:
iboQryCountry.post

That's very, very easy to work....

Sorry for my English, but I try.

Tks!

--- In IBObjects@yahoogroups.com, "Jason Wharton" <supportlist@...> wrote:
>
> 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
>