A transaction defines a set of database actions that should be executed “atomically” as a single unit. Either all of them should occur or none of them should occur, but no action should execute without all of the others.
The classic example is a transfer of money from one account to another. Suppose a program tries to subtract money from one account and add it to another. After it subtracts the money from the first account, however, the program crashes. The database has lost money — a bad situation for the owners of the accounts.
On the other hand, suppose that the program performs the operations in the reverse order: First it adds money to the second account and then subtracts it from the first. This time if the program gets halfway through the operation before crashing, the database has created new money — a bad situation for the bank.
The solution is to wrap these two operations in a transaction. If the program gets halfway through the transaction and then crashes, the database engine unwinds the transaction when the database restarts, so the data looks as if nothing had happened. This isn’t as good as performing the whole transaction flawlessly, but at least the database is consistent and the money has been conserved.
To use transactions in Visual Basic, the program uses a connection object’s BeginTransaction method to open a transaction. It then creates command objects associated with the connection and the transaction, and it executes them. When it has ...