With the first prepare of a query associated with a transaction, a physical transaction is automatically started. Under most circumstances IBO will make sure that the physical transaction will not be around for too long but if you feel the need to make sure that a transaction isn't open for too long here are some ways that the physical transaction can be closed.
The following methods of the TIB_Transaction or TIBODatabase component will close the physical transaction:
When Close is called it will attempt a Commit if AutoCommit is true; otherwise, Rollback is used. If an exception takes place during the Commit it will go ahead and just Rollback instead. Calling this method also causes all datasets associated with the transaction to be closed. If the Transaction object is destroyed and still active this method gets called in the destructor.
Calling Commit or Rollback causes the physical transaction to end and each dataset performs its CommitAction setting. The default action for native IBO datasets is to close and for the TDataset components is to stay open but invalidate a cursor if one is still open (unfetched records on the server). The dataset will refresh if there was an open cursor in order to establish a new cursor after the transaction ends.
Refresh is essentially the same as calling Commit or Rollback except that it forces all datasets to refresh in conjunction with the ending of the physical transaction regardless of what their CommitAction property is set to.
ChangeIsolation is just like Refresh except that it allows you to change the isolation used by the transaction. That is, you cannot directly change the Isolation property while a transaction is active, this function allows you to refresh the transaction and change its Isolation in the short time that the transaction is inactive.
The Pause/Resume methods allow the developer to stop a transaction without closing all the associated datasets and essentially freeze the application until the user is ready to go back to work. The transaction can then be resumed. This is useful for the cases where a large dataset would constantly have the system refreshing in order to maintain an open dataset and not keep a physical transaction open for too long.
CommitRetaining, RollbackRetaining and SavePoint do NOT result in a reset of the physical transaction.
