At 10:17 AM 7/26/2001 -0500, Woody wrote:

>Ann, most newsgroups that I read have posts that say that transactions in
>Delphi should be set to (Read Committed, No Wait, Record Version). I am
>interested in why you say that Read Committed shouldn't be used. Most
>opinions state that having this setting allows you to have an updated view
>of data in a multi-user environment so that you are always working with the
>latest version of the records in a table. Other than reports or static views
>of data, why wouldn't you want it that way?

One of the primary properties of a transaction is consistency - ask
the same question twice in the same transaction and you'll get the
same answer.

If you want a rolling view of data, you should commit between statements.
Commit when the statement completes and start the next transaction when
the next statement is invoked. I realize that Delphi doesn't work that
way - once you've committed you've lost your data. (Or is that a property
of BDE? IBX?) Their design decisions don't affect my absolute certainty
that having a user mull over data in an open transaction is a bad thing.

In a browsing application with think-time for the user, committing after
every statement is not unreasonably expensive since the transaction start
rate will be less than one per second. On the other hand, when inserting
records in a loop, with no interaction, committing every statement IS a
major source of overhead, potentially starting hundreds of transactions
per second.


Regards,

Ann
www.ibphoenix.com
We have answers.