Subject | RE: [IBO] Need a little guidance with transactions |
---|---|
Author | Support List |
Post date | 2011-07-15T21:26:14Z |
Lane,
The way I deal with this is I use the IBF_Base.pas form which itself allows
you to define a transaction context for the form. You can have it create its
own transaction or you can pass in an existing transaction you want the form
to participate in.
The question here is you need to clearly determine what your application
needs a transaction for and then design your application so that this
remains organized.
Based upon the design you have described, it seems to me there wasn't any
effort to use specific logical units of work beyond a single form. And, it
sounds like it has the flaw of putting all forms into a single transaction.
I suspect this was setup to use the transaction in AutoCommit mode.
Regards,
Jason LeRoy Wharton
www.ibobjects.com
> I inherited an application in which my predecessor defined anThis is a very good question.
> IBOTransaction and applied it to over a hundred datasets. (I'm shepherding
> about 200k lines of code, so I've not gotten around to changing it because
> it was working ... sort of). Still, I'm questioning whether the app is
> using transactions in the right way.
>
> The app (Delphi) has several data modules, and about 1,000 queries. It
> also has a couple of forms that are being used in an MDI-type environment,
> meaning that several instances of each can be up and showing. Because of
> this, each form has TIBOQueries attached to it, so that each form gets its
> own instantiation of its queries -- thus preventing the forms from
> "stepping on each other".
>
> Each form's queries have a "parent/multi-children" relationship, so when
> the user saves/applies, a transaction & rollback on error is indicated;
> therefore in this case, the transaction object actually gets used. But I'm
> wondering -- sharing the single transaction among multiple forms -- is
> probably wrong. Should I instead place a transaction object on the form,
> such that there's a separate instantiation of it, along with the queries
> that depend on it? Would this be a cleaner overall approach?
>
> Looking for advice, and perhaps a better handle on the practical use of
> transactions...
The way I deal with this is I use the IBF_Base.pas form which itself allows
you to define a transaction context for the form. You can have it create its
own transaction or you can pass in an existing transaction you want the form
to participate in.
The question here is you need to clearly determine what your application
needs a transaction for and then design your application so that this
remains organized.
Based upon the design you have described, it seems to me there wasn't any
effort to use specific logical units of work beyond a single form. And, it
sounds like it has the flaw of putting all forms into a single transaction.
I suspect this was setup to use the transaction in AutoCommit mode.
Regards,
Jason LeRoy Wharton
www.ibobjects.com