At 05:00 PM 12/01/2004 +0800, you wrote:

>Last question. You say that commit is much favorable because it uses
>less cpu and etc. but how about the resources needed to connect

A lot. But you don't connect every time you start a transaction. You do
it once per session.

> or open transaction

You don't open a transaction. You start it and you commit it (or roll it
back).

>or open table again?

You never "open a table" either. You start a transaction, then you query
the table and get an image back, which is one or more rows. This image
stays the same until you requery the table(s) and get a fresh image. Your
client application does what it wants with this image: it can pick up a
row at a time and move it somewhere else (e.g. into a buffer) or it can
fetch groups of rows and leave some still waiting on the server. If you
use a "dataset" component, you are storing this image - not physical data
from the database. Your application never touches that.

>Could this be not take to long?

Well, since I know you are using IBO, you have all the gadgetry to minimize
the amount of stuff that has to happen for you to get a fresh view of the
data that match your query specification. Apart from that, I don't
understand the question.

>Does IBO automatically make a commit if the application is close?

Yes. It's Delphi. The destructors take care of tidying up pending
work. During the process, each transaction tries to commit and, if it
fails, it rolls back. But first, it takes care of any datasets that it
opened, and asks for any remaining unfetched rows. If you have an app that
has thousands of unfetched rows, the commit call won't be made until
fetching finishes. That can take a lot of time. So your users could mess
things up by getting impatient and crashing out of your app....

/hb