> 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