Jason,

I took a look at the TfrmBase.CreateWithContext() constructor in
IBF_Base.pas and this looks like a perfect fit for my app. All my child
forms already descend from a single base form and it should be fairly easy
to plug-in a variation on this theme.

In my app, I have a global data module used to hold a session component, a
connection component and a transaction component that I assign to the
DefaultTransaction property of the connection component. Is it safe to use
this transaction for all child forms that only require read-only result
sets, then on child forms requiring live result sets, use a separate
transaction on the child form ?

Also, I have a few data modules used to perform intensive table based
calculations and updates. These data modules are used throughout the app and
a separate instance is created in the constructor of the child form. In you
opinion, is this an acceptable use of data modules and will this cause me
any problems ? I really need to encapsulate the data access components and
calculations.

Thank again,

Chris Landowski
Dynamic Software Solutions

----- Original Message -----
From: "Jason Wharton" <jwharton@...>
To: <IBObjects@egroups.com>
Sent: Wednesday, January 10, 2001 9:36 AM
Subject: Re: [IBO] Proper Transaction Usage in an MDI App


> > Look at a artilcle at undu.com. (Great site btw...) There is a few
> article's
> > how to load an 'privat' datatamodule for every childwindow.
> > http://www.undu.com/Articles/981229d.html. I think this wil do the
trick.
> > I'am just starting a project where a want to do the same as you.
>
> I prefer to see people simply omit data modules from their applications
> except for holding the global things like a session and connection
> component.
>
> I also use on each form (for an example see my base class IBF_Base.pas) a
> connection link and a transaction link. This way, a form can be introduced
> into a transaction context or you can create your own. Then you hook into
> the BeforeAssignment event and control the entire context for the form.
This
> allows a form to have its own context or to be introduced into a context
> from a form that may have launched another form with a button click or
> something.
>
> See the TfrmBase.CreateWithContext() constructor of my sample. It shows
how
> I have this all setup. Because I use this form all the time it
automatically
> does just what I expect.
>
> Data modules are for apps written with the BDE where you could only have a
> single transaction in the whole app. If you really want to feel at home
with
> IBO, start getting used to dropping data modules from your apps and
putting
> transactions and datasets on forms.
>
> To me, the form itself is an independent object and it should contain its
> data access mechanisms the same as anything else. Otherwise it is not an
> independent object.
>
> Note, my apps tend to have multiple instances of the same form so I cannot
> use datamodules for this style. I suppose there are hacks that still allow
> this but I loathe hacks and only use them if I must. In this case I don't
> have to use them.
>
> The trick is to use form inheritance so that a lot of the mundane data
> access code is in its own layer and then you still have your separation of
> data logic from the interface logic.
>
> FWIW,
> Jason Wharton
> CPS - Mesa AZ
> http://www.ibobjects.com
>
>
>
>
>