Transactions and You

Transactions are useful or even necessary when you need to make several changes at once. Think of a transaction as a logical unit of work. And if any part of the transaction fails, the whole thing is rolled back (i.e. any changes made since the beginning of the transaction are undone). The example often used in computer books is one drawn from banking. For example, let's say that you go to the bank to pay a bill. The funds are drawn from your account and placed in the electric company's account. So two things happen. First the funds are debited from your account and second, the funds are credited to the electric company's account. If the funds are not drawn from your account but are credited to the electric company, you are happy but the bank is not. If the funds are drawn from your account but not placed in the electric company's account, you are mad and the electric company is not that happy either. So both parts of the transaction must occur properly (i.e., the transaction is committed) or both part of the transaction are not executed (i.e., the transaction is rolled back).

Computer scientists use the acronym ACID to define the characteristics of a transaction.

Atomicity - Although the changes may include several records, if anything fails the entire transaction fails. The system goes back to a pre-transaction state.
Consistency - A transaction never leaves the database in an inconsistent state. If a change is made, it can be undone if the transaction fails at a later point.
Isolation - A transaction behaves as if it were in complete isolation from other transactions in the system.
Durability - Once a transaction's changes are committed, they persist beyond any system failure. If the system crashes (or GPF's!) after the transaction is committed, the transaction's results are still maintained.