Subject | Re: [IBO] RE: help |
---|---|
Author | Jason Wharton |
Post date | 2002-02-27T16:46:40Z |
Transactions are a way to have logical units of work. That is how you need
to look at them. MIDAS has its requirements because it is a poor data access
approach and requires lots of things to be certain ways because of its own
deficiencies, not because it is a more correct way of doing things.
If a master is cancelled then you should have referential integrity to
delete all orphan records. Referential integrity constraints will do this
for you. In IBO, you don't get an inserted detail record without the master
record existing. The master will have a PostRetaining done for you (unless
you are using cachedupdates) when the detail record is posted. This means
the master record appears to still be in insert mode but the record has
already been inserted onto the server. If you cancel then it is deleted from
the server. At this point is when Ref Integ will tidy up any detail items.
In short, IBO puts the server in charge of many things that otherwise would
require lots of hoops to be required on the client app side. Also, use a
single transaction for master-detail situations. You will only confuse
yourself and set the stage for problems if you try and coordinate two
transactions here.
HTH,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
to look at them. MIDAS has its requirements because it is a poor data access
approach and requires lots of things to be certain ways because of its own
deficiencies, not because it is a more correct way of doing things.
If a master is cancelled then you should have referential integrity to
delete all orphan records. Referential integrity constraints will do this
for you. In IBO, you don't get an inserted detail record without the master
record existing. The master will have a PostRetaining done for you (unless
you are using cachedupdates) when the detail record is posted. This means
the master record appears to still be in insert mode but the record has
already been inserted onto the server. If you cancel then it is deleted from
the server. At this point is when Ref Integ will tidy up any detail items.
In short, IBO puts the server in charge of many things that otherwise would
require lots of hoops to be required on the client app side. Also, use a
single transaction for master-detail situations. You will only confuse
yourself and set the stage for problems if you try and coordinate two
transactions here.
HTH,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
----- Original Message -----
From: "Gerald W. McCaig - Efi Soft" <gwmccaig@...>
To: <IBObjects@yahoogroups.com>
Sent: Wednesday, February 27, 2002 1:06 AM
Subject: RE: [IBO] RE: help
> Hi Jason,
>
> I guess I am used to the MIDAS way, where you need a transaction for every
> Query/Table. Also, I like to have more control over what is happening, and
> that is why I have used two transactions. Is there a downside to doing
this?
> I have always been told multiple transactions keep a tighter control over
> what is going on, by separating your actions.
>
> Anyway, bottomline, I need to know how to cancel and delete items in the
> DETAIL, without compromising my ability to roll everything back if the
user
> decides to cancel the MASTER.
>
> Thanks,
>
> Jerry
>
> -----Original Message-----
> From: Jason Wharton [mailto:jwharton@...]
> Sent: Wednesday, February 27, 2002 12:35 AM
> To: IBObjects@yahoogroups.com
> Subject: Re: [IBO] RE: help
>
>
> Jerry,
>
> In short, what you are trying to do with transactions doesn't make any
sense
> to me. It would help if you told why you are using two transactions. At a
> first glance it looks like you are over complicating something that should
> be much more simple. Apologies that I have merely skimmed over this just
> giving my impressions.
>
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
> ----- Original Message -----
> From: "Gerald W. McCaig - Efi Soft" <gwmccaig@...>
> To: <IBObjects@yahoogroups.com>
> Sent: Tuesday, February 26, 2002 7:46 PM
> Subject: [IBO] RE: help
>
>
> > Hi Jason,
> >
> > I have a question, in regards to the IBO Query & Transaction...
> >
> > My application has a screen where you can create a new record, and then
> > multiple detail items under that record. So, I am running two
transactions
> > on two queries. I am having a problem though. I am only committing the
> > changes to the detail right before I commit the changes to the master
> > record. The problem is, if I add a few items, then begin adding
> > another...but made a mistake...and need to cancel the current one or
> delete
> > one that was in error, the record still shows open and also posts when I
> > commit the transaction.
> >
> > Let me give you a brief code overview, and maybe you can tell me where I
> am
> > going wrong...
> >
> > ----------------------------------------------------
> >
> > if not MasterTrn.InTransaction then
> > MasterTrn.StartTransaction;
> >
> > MasterQry.Append;
> > ---
> > if not DetailQry.InTransaction then
> > DetailQry.StartTransaction;
> >
> > DetailQry.Append;
> > ---
> > [if Detail OK] DetailQry.ApplyUpdates;
> > ---
> > [if Detail Cancel] DetailQry.CancelUpdates;
> > ---
> > [if Detail Delete] DetailQry.Delete;
> > ---
> > [When Master is Posted]...
> > if DetailQry.InTransaction then
> > DetailQry.Commit;
> >
> > MasterQry.ApplyUpdates;
> >
> > If MasterQry.InTransaction then
> > MasterQry.CommitRetaining;
> > ---
> > [When Master is Canceled]...
> > if DetailQry.InTransaction then
> > DetailQry.Rollback;
> >
> > MasterQry.CancelUpdates;
> >
> > If MasterQry.InTransaction then
> > MasterQry.Rollback;
> > ----------------------------------------------------
> >
> > So, for example: I create a Master Record, I add 6 Items,
> > but two of them were canceled during entry, when I save
> > the Master, all 6 get recorded. I know that if I commit
> > the transaction after each detail item that it will solve
> > this problem, but it creates another problem because it
> > doesn't rollback the six records automatically if I cancel
> > the Master.
> >
> > Any ideas? Please.
> >
> > Jerry
>
>
>
>
>
___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or
InterBase
> without the need for BDE, ODBC or any other layer.
>
___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info
papers,
> keyword-searchable FAQ, community code contributions and more !
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
>
___________________________________________________________________________
> IB Objects - direct, complete, custom connectivity to Firebird or
InterBase
> without the need for BDE, ODBC or any other layer.
>
___________________________________________________________________________
> http://www.ibobjects.com - your IBO community resource for Tech Info
papers,
> keyword-searchable FAQ, community code contributions and more !
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>