At 03:45 PM 21/07/2003 +0200, you wrote:

>Hi,
>
>IBO defaults to itCommitted,

No. The only transaction object that defaults to tiCommitted is
TIBODatabase. Both TIBOTransaction and TIB_Transaction default to
tiConcurrency.

>and has the following default behaviour:
>After a select a transaction starts.

No. A transaction must be started in order for a select statement request
to be submitted. What happens if you don't take explicit control of the
transaction is that IBO starts the transaction for you if it's not already
started. If you don't prepare a statement in a TIBOQuery, IBO prepares it
for you (and, for datasets, it's generally correct to let IBO take care of
this).

>It will only commit after a selected period of time

It will only commit if your application commits it. TIBODatabase defaults
to AutoCommit - this means that the transaction will be committed, using
CommitRetaining, every time you post an update. Alternatively, if you are
using explicit transaction control (i.e. not autocommit) the transaction
will be committed when you commit it; otherwise, it's not committed.

>After updating records IBO generates a COMMIT RETAINING and leaves
>committing the transaction to the timer.

No. IBO doesn't update records. It submits (posts) an xxxSQL statement to
the server. If you keep AutoCommit true, Post is immediately followed by
CommitRetaining. This keeps the current transaction context open and it's
not a great way to run a client/server application. Your code must
regularly perform at hard Commit. For this you need to start the
transaction yourself (thus overruling AutoCommit) and call Commit explicitly.

Note that statements are posted and transactions are committed. So
autocommit causes all statement objects - not just the one you are posting
- to be checked for pending DML.

>This works fine, but if I want to protect users better from changing
>eachother records I can go to itConcurrency transactions.
>So in that case, what do I have to do to merge as easy as possible into IBO
>default behaviour ?

I don't understand what you mean by "merge into IBO default
behaviour". IBO default behaviour is to have you control transactions
yourself. With the TIBO* components, you get VCL default behaviour, which
isn't ideal for serialising DML operations. If you want tiConcurrency,
just select it. If you want to control the transaction yourself (and you
do, to enforce serialisation) deselect AutoCommit to break out the updating
sequence into post (the statement) and either Commit (if post succeeds) or
Rollback (if there is a locking conflict).

>1.just perform a hard "commit" after each select statement in code.

No, not if you want a live dataset. A transaction has to be active in
order to do DML operations.

> this means: just depend further on the "commit retaining" after post
>behaviour and the timer who really commits every n minutes ( IBobjects
>behaviour ) ?

No. If you always use autocommit, then you always get CommitRetaining
(like the BDE) . There are various ways you can set up to have
transactions *time out* when they appear to be unused - including setting a
timeout interval, prompting the user, etc. See the TimeOutProps.

>2.perform a "commit retaining" after each select statement and leave
>everything else to IBobjects ?

If you use explicit transactions instead of AutoCommit, then you can call
CommitRetaining yourself, if you want to. But CommitRetaining isn't great
for tiConcurrency transactions because users won't see others' changes,
even if you call Refresh. With CommitRetaining, only a tiCommitted ("Read
committed") transaction will see others' changes on Refresh.

Helen