In my own style, I have a dConnection datamodule which houses the main
connection(s) to the database. No Transactions please.

Each form / report has its own datamodule where the Transaction and Datasets are
housed, and this datamodule uses the dConnection to link in the main
Connection(s).

I think it is pretty haphazard to share the same Transaction with different
forms because if you happen to commit on one form (or close the transaction),
you would get a blank record on other forms.

Besides, associating a single Transaction with a single Form makes a lot of
sense and simplifies a lot of things. You can also easily set the Transaction's
CloseWithConfirm property so that if you close a form but forgot to commit the
changes you made, the CloseWithConfirm property will remind you.

In my own convention, I use a preface f for Form and the preface d for the
datamodule. So, if I have an fCollection form, it will have a dCollection
datamodule. This dCollection datamodule will have a Transaction object within it
which is the Transaction of the form fCollection. If I have lookup objects, the
datamodule will have another LookupTransaction which is set to readonly, and all
lookup datasets will use this transaction instead.

For Transaction settings, I like to set the Autocommit to True, but I also place
three TAction buttons on the screen for Start, CommitRetaining, and
RollbackRetaining to give the operator a choice to manually use Transaction
capability. (If you press Start, the autocommit behavior of the Transaction will
be temporarily suspended and you will have to Commit or Rollback your changes
yourself).

I place datasets in forms because I don't like to mix data with forms. Instead,
all data entities (along with the occasional temporary variables that are needed
to indicate states or contain summary totals produced by client-side processing)
are placed as fields of the datamodule object itself. So, all business rules are
really placed in Datamodules.

Joseph Alba
jalba@...




Chris Landowski wrote:

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