|
<< Click to Display Table of Contents >> Transactions |
  
|
|
<< Click to Display Table of Contents >> Transactions |
|
A transaction is a group of related operations that must all be performed successfully; otherwise no change to the database takes place.
The Borland Database Engine (BDE) supports transactions on all servers with three BDE function calls:
The application calls DbiBeginTran, submits SQL statements and BDE function calls to be included in the transaction, and then calls DbiEndTran. DbiGetTranInfo returns status information about a transaction.
BDE supports local transactions for Paradox, dBASE, and Access drivers so that updates to tables can be rolled back (reverted) or committed. Without transaction support, updates would be committed immediately with no way to roll them back and applications might fail to perform updates in a consistent way.
When a local transaction is started on a standard database, updates performed against tables in that database are logged. Each log record contains the old record buffer of the record that is updated. When a transaction is active, the records with updates are locked. These locks are held until the transaction is either committed or rolled back.
•The Commit operation releases all locks that were held when that transaction was active.
•The Rollback operation reapplies the updates to the underlying tables to restore the original state of the database. Once the original state of the database is restored, the locks are released.
| Note: | For standard transactions there is no automatic crash recovery on DDL-related actions such as table create, restructure, index creation, table/index deletion, and so on. |
For more information, see:
•Transactions on Paradox, dBASE, FoxPro, and Access is a guide to specifics.
•Cached updates offers yet another strategy for dealing with locking.
•Transactions and cached updates provides a comparative discussion.
