At 10:22 AM 10/03/2003 +0100, you wrote:

>To summarize:
>
>- It's better to change the UI with simple to understand and intuitive
>buttons instead of using the bars

I was only talking about the TransactionBar! The UpdateBar and the
NavigationBar are fine for users. In particular, make use of the global
focusing feature of the bar components (see ReceiveFocus property and
OnReceiveFocus event of the bar comp. and AnnounceFocus property of the
dataset) - it's ONE of the really cool things about IBO.

>- Do you suggest that I always start/close the transaction by myself
>(explicit transaction) instead of letting IBO do it by itself?

Sometimes.

>- Is it better, in general, to use Autocommit or is it better to
>explicitly commit/rollback in code when needed?

Sometimes.

Sorry, but these decisions need to be made by *you*, according to the
requirements for the task. Read the comments in the thread "more about
transactions"....you are not the only one who struggles with this. When
I'm designing a UI, I sit down at a table with sheets of paper and map out
the tasks. It might sound silly to you but, if you can start to think
about a transaction as "a unit of work", your own intuition will soon begin
to tell you which transaction settings will work best for each task.

>- In general, how many transactions do I have to use to operate on
>each table? One unique transaction to open/close the query and to
>perform all DML tasks on that table (as I'm doing now) or two, one to
>open/close the query and another for DML tasks? Is it safe to use one
>for all?

Yes, it's safe and normal for the main task on a form to be enclosed inside
a single transaction. It's also a good place to start - it's preferable to
beating yourself, wondering if you did the right thing...

Sometimes, you might need to keep another transaction in the wings to do
things like populating a stringlist for a combobox, or filling a
controlgrid, for times when you want to refresh it. You can just start the
transaction, get the data, load the container and then close the
transaction until next time you want it.

You'll want to keep a separate transaction available if your main
interactive form lets users print reports. You'll start this transaction
afresh each time a report is printed. Use tiConcurrency isolation, because
a report needs to be a snapshot.

Since the most usual UI is for the main part of the application to be
interactively working with scrollable datasets and operating on a single
row at a time, any DML operation that affects a batch of rows, or inserts a
bunch of rows will almost certainly be outside the context of the main UI's
work. You have various ways to synchronise data between your
transactions: the key is to use transactions in a way that keeps each unit
of work flowing along in its own context, unbothered by work happening in
other transactions.

And THESE ARE NOT RULES. They are just indications of how multiple
transactions can enhance the usability of your application.

>Well, apart the tech info taken from Jason's site and the Interbase
>manual, is there any other good (simple to understand :-) reading
>about transactions somewhere?

There isn't a book about them (yet!). But, if I ever get to write The
Book, you can be sure that it will be in there. The topic is covered
pretty comprehensively in IBPhoenix's "Using Firebird" manual. At the
moment, you need to buy the IBP CD to get it, though. I understand IBP has
plans to release the manuals on a cheaper CD distribution soon, maybe when
Firebird 1.5 is ready for release...

Other places to go are the online FAQ and the sample apps in your IBO root.

Helen