Chris,

> 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.

There is a fair amount of documentation on this class in the interface of
it.

> 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 ?

This should be fine. Pay close attention to how the connection's
DefaultTransaction affects the frmBase's behavior for resolving unassigned
(default) transactions.

> 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.

From the sounds of things you would do well to move as much of this as
possible to stored procedures on the server. The thought of there being a
lot of code on the client for data processing doesn't set well with me. This
is another reason why data modules irritate me some. The place for business
rules and data processing isn't for data modules but instead of stored
procedures.

HTH,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com