Ensuring data integrity is an important consideration when building an application.
The data in your database is most likely valuable to your business and steps need
to be taken to ensure that changes made to it are executed correctly. This is where
transactions come into play.
Transactions are used to ensure that either all or none of the steps involved in
an operation are executed. Accounting is a perfect example of why transactions are
important. It's often necessary to transfer money from one account to another.
In order to do this you need to first debit money from the source account and then
credit it to the destination account. Without transactions, if something went
wrong while processing the request, we might be left in a situation where the
money had already been removed from the source account and not yet credited to
the destination. The resulting confusion over the missing money
could cause real problems.
Continuing the same example, by placing both the debit and credit operations
into a single transaction we ensure that the funds either move to the new account
or they do not. In this example, using a transaction eliminates the possibility of
"creating" or "destroying" money. If the funds didn't get transferred then
we still need to determine the source of the error and fix it, but at least
we don't have to try and track down the missing money as well.
By default this page will execute CommitTrans in order to commit the transaction
to the database. If you would like to run the script again you can choose whether
or not it will commit (CommitTrans) or rollback (RollbackTrans) the transaction
by clicking the corresponding links above.
Please note that clicking the above links will run the script again and either
commit or rollback the insertion of a new record. It will not affect any records
already added to the database including the one shown above which was already
You should also note that I'm not really doing much of anything in the transaction
that would require a transaction. I'm doing a simple insert so that you can see
that the data does get inserted when the transaction is committed and doesn't
get inserted when it is rolled back. In the real world, you'd most likely have at least
two operations going on inside the transaction, but I'm just including one
in order to keep things as simple as possible.
You can view any data that was committed to the database via our
sample. It's probably easiest if you use the value of the
date_time_field (shown in the SQL statement above)
to locate the appropriate record.