Transactions
Go Up to Using Databases
A transaction is a group of actions that must all be carried out successfully on one or more tables in a database before they are committed (made permanent). If any of the actions in the group fails, then all actions are rolled back (undone).
Transactions ensure that
- All updates in a single transaction are either committed or aborted and rolled back to their previous state. This is referred to as atomicity.
- A transaction is a correct transformation of the system state, preserving the state invariants. This is referred to as consistency.
- Concurrent transactions do not see each other's partial or uncommitted results, which might create inconsistencies in the application state. This is referred to as isolation.
- Committed updates to records survive failures, including communication failures, process failures, and server system failures. This is referred to as durability.
Thus, transactions protect against hardware failures that occur in the middle of a database command or set of commands. Transactional logging allows you to recover the durable state after disk media failures. Transactions also form the basis of multi-user concurrency control on SQL servers. When each user interacts with the database only through transactions, one user's commands cannot disrupt the unity of another user's transaction. Instead, the SQL server schedules incoming transactions, which either succeed as a whole or fail as a whole.
Transaction support is not part of most local databases, although it is provided by local InterBase.
For details on managing transactions, see:
- Managing Transactions Using FireDAC
- Managing Transactions Using Other Database Frameworks
- Managing Transactions Using BDE (deprecated)
In multi-tiered applications, you can create transactions that include actions other than database operations or that span multiple databases. For details on using transactions in multi-tiered applications, see Managing transactions in multi-tiered applications.