Subject | Re: [IBO] Proper Transaction Usage in an MDI App |
---|---|
Author | Geoff Worboys |
Post date | 2001-01-10T08:31:44Z |
> I have tried using a single transaction on a shared datamodule butEach form must create create its own copy of the datamodule (with its
> when I go to post my changes, datasets on other child forms that
> are in an edit state automatically post.
own internal reference to that module).
I too use a MDI(ish) application, previously I have always put the
transaction and datasets of the form itself. However I am now
contemplating the use of DataModules for other reasons.
> I would like the changes made in one child form visible to theThis seems like a contradictory statement. The datasets on other
> remaining child forms as soon as they are posted, but do not want
> datasets on other child forms affected.
child forms are the way the child forms will see such changes.
However they will not see the changes until they refresh. This can
either be done manually or automatically (initiated in your own code)
depending upon requirement.
> I would also prefer to keep the transactions as short as possible.Dont we all ;-) You need to be practical about this (or in extremes
> Is the default transaction even an option for me ?
use CachedUpdates). My preference is to use Transaction Pausing
capabilities (see the tutorial in the source), but I believe many find
IBOs automation acceptable for day-to-day use.
There is a form in the IBO source TfrmStatus in IBF_Status that you
can create to monitor the status of transactions and datasets in your
application. This can be useful during development to watch what is
happening.
So much about transactions is application dependant that you often
have to implement and then tune according to what you see and what you
need.
Geoff Worboys
Telesis Computing