Subject | Re: [IBO] Controlling IB_Transaction |
---|---|
Author | Andreas Pohl |
Post date | 2001-03-19T08:55:01Z |
Claudio,
I want to achieve right that what you are referring about and I'm ashamed
about my stupid failure (nobody should know that I'm working with IBO for so
long time). Normally I assign all of my stuff at runtime, in this specific
issue I did it at design time. I think I cut my txn comp once, so IBO
assigned a default one automatically. This default transaction is working
with autocommit for sure. I've overlooked my assigning failure so I blamed
it to the master detail stuff first. Than my time was running, my nerves are
blank, my childs are screaming, rain started to fall and I've to go for a
400 km car trip...
Now I'm back, problem was found/solved, it is still raining and I thank you
for your reply :)
Mit freundlichem Gruss & Best Regards
Andreas Pohl
apohl@...
www.ibp-consult.com
I want to achieve right that what you are referring about and I'm ashamed
about my stupid failure (nobody should know that I'm working with IBO for so
long time). Normally I assign all of my stuff at runtime, in this specific
issue I did it at design time. I think I cut my txn comp once, so IBO
assigned a default one automatically. This default transaction is working
with autocommit for sure. I've overlooked my assigning failure so I blamed
it to the master detail stuff first. Than my time was running, my nerves are
blank, my childs are screaming, rain started to fall and I've to go for a
400 km car trip...
Now I'm back, problem was found/solved, it is still raining and I thank you
for your reply :)
Mit freundlichem Gruss & Best Regards
Andreas Pohl
apohl@...
www.ibp-consult.com
----- Original Message -----
From: "Claudio Valderrama C." <cvalde@...>
To: <IBObjects@yahoogroups.com>
Sent: Monday, March 19, 2001 9:14 AM
Subject: RE: [IBO] Controlling IB_Transaction
> > -----Original Message-----
> > From: Geoff Worboys [mailto:geoff@...]
> > Sent: Sábado 17 de Marzo de 2001 8:59
> >
> > > First I connected all of my queries with mastersource
> > > properties but I noticed that posting a detail row will
> > > post master row implicitly. So I chained queries by myself
> > > now to avoid that.
> >
> > Just curious, why did you decide to do this? I thought the implicit
> > posting of the master dataset was one of our greatest achievements :-)
> > It allows a complex structure to be presented to the user as a single
> > object, with the automation taking care of the interdependancies
> > automatically.
>
> With the master-detail functionality behind scenes taking care of the
> interdependencies, maybe you wanted to say, Geoff. Or perhaps I spoiled
your
> explanation even more.
> I agree with you: I set up a master detail and when the detail is going to
> do the first post, the master does an implicit post (otherwise, db
integrity
> would catch you) but it remains on logical edit state. Then I continue
> filling the detail table, usually bound to a grid with only a few fields.
> Since a transaction is in effect, nobody outside this txn can see the
> insertions. When I ask the user to confirm or discard changes and the user
> wants to cancel, I don't call master.cancel because it would attempt to do
a
> delete to compensate for the implicit post and so I would need to either
> delete the child's records or rely on cascade deletes. I simply rollback
the
> transaction. All changes seen by the db will discarded, so why bothering
to
> avoid the implicit IBO mechanism and reinvent the wheel? Andreas, what's
> your point against this IBO facility? After all, if the master and the
> detail are using the same txn (this is the only reasonable way IMO), all
> records will be ignored if the txn is rolled back. It seems to me that you
> finally are doing the same than IBO. Remember, the txn isolates all the
> changes.
>
>
> > > Anyway, after finishing procedure I would like to ask user
> > > if transaction should be saved and call CommitRetaining/
> > > RollbackRetaining depending on users choice.
> >
> > My preference is to use Transaction.Refresh(true) for commit and
> > Transaction.Refresh(false) for rollback. This way the transaction is
> > fully reset. CommitRetaining will retain the existing transaction
> > context and so continue to hold up any processing that may be waiting
> > on the transaction to end. (RollbackRetaining is an IBO simulation
> > and will result is a full transaction reset anyway.)
>
> This was in the Jurassic, Geoff. In the Cretaceous, IB implemented
> RollbackRetaining and then IBO followed suit and only simulated things for
> IB5 and earlier but now it calls the API for IB6, by detecting the engine
> version. (This brings to my mind the issue of server version in Firebird.)
> Well, this is what the help file says. It seems that Jason changed his
mind
> afterwards so either the help or the code should be amended to be in sync:
> procedure TIB_Transaction.API_RollbackRetaining;
> has the call to the API commented and does the IBO emulation always. What
> happened, Jason?
>
> C.
>
>
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>