Do I need to use database transactions with c# TableAdapters?

I found this great article on Transactions with Table Adapters. However, this article doesn't explain why Transactions are needed or even desirable!

Why would it be worth me trying to i开发者_如何学编程mplement Transactions alongside my TableAdapters?

Suppose that something bad happens when you are in the middle of saving something that takes more than one query to the database. What do you want to happen to all data that has already been saved when you began the save operation? Most of the developers want to invalidate the data that has been saved previously. Well.. that's what transactions are for: you encapsulate all the save logic in a transaction so that if/when something bad happens in the middle, nothing is saved.

More on the Transactions subject: http://en.wikipedia.org/wiki/Database_transaction

The "why" would be to perform those database operations as part of a wider transactional unit, so that you can commit that and other things in an atomic (all-or-nothing) way, or ensure that your reads and writes happen in the same transaction (to avoid phantom/non-repeatable reads). Actually I'm not a huge fan of the adapter model, but...

For how; TransactionScope would be simpler, since ADO.NET connections should auto-enlist:

using(var tran = new TransactionScope()) {
    // do work A
    // do work B
    // do work C
    tran.Complete();
}

job done...

If you ever have the situatino where you have multiple tables that you want to have a guaranted update for in an atomic call, transactions make this possible. Without transactions you may be able to update one table, then the second fails and you are left with problem data. For example, you may have the situation where yuo have one screen and want to add a parent record and a bunch of child records with a single button click. Without transactions, the parent successfully saves but one of the child records blows up. With transactions, you rollback the whole thing and ask the user to fix the data problem.

Transactions allow you to maintain data consistency in database. It is usually preferred to introduce Transactions in all database updates/inserts. You always rollback if a specified stored procedure fails for any reason.

Every this you guys have posted here it sound good to me but we shouldn’t forget that against a solution there are always vantages and disadvantage For example managing the transaction on the application side (doesn’t matter how) you are going to increase the network traffic because .net has to send all the command to SQL Server:

using(var tran = new TransactionScope()) {

// do work A 

// do work B 

// do work C 

tran.Complete(); 

}

In this case it has to send a “begin transaction” and “commit” .

The worst think can happen is what does it happen if after “//do work b” the connection cut off?. It means the .Net won’t be able to send neither the “rollback “ or” commit” so that we are going to have a opened transaction on the SQL Server side that can cause dead-lock.