ASP Transactions
by Chris Payne Introduction
Transactions are important to maintain data integrity, among other things, and have been used with 
databases for some time now. Luckily, transactions aren't restricted to databases - you can use them in 
Active Server Pages as well, and without having to create custom components using Microsoft Transaction 
Server (MTS). This article will take a look at what transactions are, how they will help ASP developers, 
and how to implement them. 
What are Transactions?
Before we dive into the meat, we have to understand the terminology (believe me, I was lost for a long 
time because no one explained these terms to me). 
Basically, using a transaction means it's an all-or-none deal. No halfways, no maybes. Let's suppose 
you're modifying a database, and you have to add 100 new items, one at a time. Before adding each item, 
however, you have to check to make sure it fits certain criteria - if it doesn't, then your database 
cries, you receive an error, and the process quits. It may not be desirable to quit halfway - for whatever 
reason, you either want all the new rows or none of them. 
Enter transactions. If you put the process in a transaction, and if an error occurs, the transaction 
will "roll back" to a state just before you started your process. Thus, if any of the new items doesn't 
meet the criteria, none of items gets added, instead of only the first few. 
The classic example is a banking application. Suppose someone wants to transfer funds from one account to 
another. You would deduct x amount from account A, and then add it to account B. Suppose after you have 
deducted the money from account A (and before you add it to account B), you notice a problem (perhaps 
account B has restrictions, or is not available for some reason). If the application just quits here with 
some error message, then account A will be in an incorrect state, meaning it has funds missing. These 
funds are not in account B yet, so they are just floating off in cyberspace, and you have one very unhappy 
customer. With transactions, should you encounter this error, the process will roll back to a previous 
state, and the money will automatically go back to where it started. If there are no problems, however, 
the transaction will commit, and everything will go through. 
Another example more apropos to web development is user registration. Suppose a user comes to your 
community building web site and decides to register. Once they submit their information, you have to enter 
it into a database, and also set up their personal web page. Thus, every user in the database must have a 
personal web page as well, or no one will ever know that they are there. Your ASP script adds the user 
into the database perfectly, but a server error causes your web page building routine to fail 
unexpectedly. You now have a floating user - a user in the database, but without a web page. If this 
process were transactional, you could roll back to just before you inserted the user into the database 
(thereby eliminating the floating user problem), and gracefully display a nice error message to the user. 
Pretty slick, huh? 
So How Does it Help Me?
It's always got to be about "me," doesn't it? Well, if you didn't gather it from above, transactions are 
mainly used for error handling. They stop you from getting in weird positions that you can't get out of by 
easily allowing you to 'undo' the changes you've made. As you develop more and more complex web 
applications, the need for strong state protection will become increasingly necessary. 
What is MTS?
MTS is Microsoft's answer to transactions. We won't go into too much detail here, but MTS is the engine 
that keeps tr