Almost everything that happens in an InterBase database happens within the context of a transaction. Transactions are at the heart of any well implemented client/server application. With IBO you have 100% visibility and control over what is happening with transactions in your application. With this comes the responsibility to understand how to manage transactions.
It will be very important that you know these aspects because there will be frequent mention of them in the rest of this document. I find it easiest to break the transaction concept into three distinct parts or aspects: Explicit, physical and logical.
Explicit Transactions
The aspect that most people will be familiar with is the explicit transaction. This is when the developer takes explicit control over a transaction. In the BDE this was done by calling the StartTransaction, Commit and Rollback methods. This allowed the developer to have explicit control over their transactions but shielded them from having to know what all was going on under the hood in order to accomplish it. The InTransaction property tells whether or not an explicit transaction has been started.
In IBO explicit transactions work exactly as they did with the BDE so there should be no serious problems if you want to go on working the way you did before (as long as you were doing things right).
Physcial Transactions
Physical transactions have been hidden from view in the BDE but now they are fully exposed. IBO starts a physical transaction whenever one is needed automatically. The physical transaction represents the actual existance of a transaction on the server and the presense of a transaction handle on the client. The Started property tells whether a physical transaction has been started or not.
From the moment a physical transaction is started, InterBase sets up a context which "protects" this transaction from other changes being processed in the database. It also provides the context of conflict management if two users try and update the same pieces of information.
The protection of a transaction means that InterBase is prevented from performing garbage collection beyond the oldest active transaction (OAT). In addition to this, while-ever a transaction has uncommitted changes to records it prevents another user from performing additional changes to those records. Because of this a physical transaction should not be kept open unnecessarily for long periods of time.
IBO has various mechanisms to make sure that a physical transaction is only held open when absolutely necessary. For the most part, IBO takes full control of physical transactions for you. There will be more discussion about the OAT management issues later on.
Logical Transactions
The logical transaction aspect has to do with updates, etc. being sent to the server. This is what defines a unit of work that is committed or discarded as a whole. As soon as a dataset goes into an edit state or an SQL statement that results in a DML or DDL is successfully executed, there is a logical transaction present.
The TransactionIsActive property tells whether or not a logical transaction is present. A logical transaction ends when a batch of work is either committed or rolled back using any of the methods that accomplish this.
The reason this aspect is distinguished from the others is because it is possible for an explicit transaction to be started by calling the StartTransaction method but if the user doesn't actually make any changes there really isn't a logical transaction even though there is an explicit one. It is very useful to know when a user has actually made some changes or is about to regardless of the presense of an explicit transaction.
It makes no difference whether Commit or Rollback is called if there isn't a logical transaction present. There are no changes to worry about losing. In many cases the physical transaction is ended when the logical transaction is ended but this isn't always the case.
