Let's say I have a form for just name and address information. Users
periodially go there and to edit and add informaiton. If I understnad
correctly you'd recommend using: 1) an instantiated transaction 2)
Autocommit 3) a timer to periodically issue a "commit". Do I have this
right?

If I just use the default transaction, it Autocommit true?

--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
> At 06:02 AM 19/03/2004 +0000, you wrote:
> >When converting a standard data entry application (several forms where
> >the user edits and adds data) from BDE to IBO, what are some
> >guidelines for using transaction components? Place one per form, with
> >Isolation tiCommitted and AutoCommit true? Just lean on the default
> >transaction to do the work?
>
> As a permanent solution, no, can't generalise. There's no "formula"
that
> you can apply to turn a BDE app into a good client/server app.
Application
> design should be task-oriented and "a task" should be wrapped in a
> transaction. Past that, it's a question of workflow.
>
> Autocommit true as a rule to abide by, no way. In your design, you
have to
> work out which tasks need autocommit and, if you use it, *always*
> instantiate that transaction. Use autocommit for transactions that
require
> it, but wrap its use inside a timed explicit commit cycle.
>
> When getting into refactoring, don't use autocommit for the default
> transaction.
>
> However, to get you *started*, do whatever you were doing in the BDE
> app. That's a pretty good way to find out where the bottlenecks are.
> People tend to come grief if they try to guess things at the
conversion stage.
>
> Helen