views:

540

answers:

7

Hello gurus,

When my C#.net application updates records in more than one table, I use transactions so if anything should fail during the transaction I can rollback.

Which one is a better practice?

-Use stored procedure with BEGIN TRANSACTION/ROLLBACK/COMMIT TRANSACTION; -Use TransactionScope in the application as below:


    using (TransactionScope ts = new TransactionScope())
    {
    }

+1  A: 

In application. Generally speaking the less logic you have in the database the better.

zvolkov
i think if an answer gets voted down the least someone can do is explain why (i have voted up) its a contentious answer but its a valid stand point that has a huge dependence on the solution you are working on
Matt
I wasn't the down-voter, but if it has a "huge dependency on the solution you are working on", then saying that it "generally" is better to not put logic in the DB isn't very accurate.
Tom H.
I'll be interested in hearing the arguments in support of having as much logic in DB as possible.
zvolkov
acknowledged Tom, i'd still prefer a comment when someone downvotes, maybe it could be made mandatory, most of the chaff will be closed anyway
Matt
I didn't down vote this but I don't agree with the advise. It misses the point to having multiple tiers. The problem is to figure out which tier is the best place for a piece of logic. The answer isn't always the middle tier.
Glenn
+1  A: 

TransactionScope is a really nice way to manage transactions in code. It allows you to nest transacted code across multiple methods, and automatically scales up to distributed mode, if necessary.

I prefer to use TransactionScope over stored proc transactions, because it gives you a lot more control in the code.

Andy White
+1  A: 

Or you can do it in both. Check the link: http://www.4guysfromrolla.com/webtech/080305-1.shtml

Mike C.
+3  A: 

This isn't a business logic issue, it's a data integrity issue and I feel that is ok to do in the stored procedure. I like to keep transaction logic as close to the operations as possible to shorten their duration.

Mufaka
He said his app updates records in more than one table. That means he either needs to open the tran in one proc and commit in another, or he needs to have all logic in one proc (or in multiple procs calling each other) which is never a good thing...
zvolkov
True, db transaction should end as fast as possible. The opposite is never a good thing.
Constantin
You can have a transaction open accross multiple tables, multiple databases, and even servers. Like Mufaka says, best to let the sql server handle it's own transactions or you could have som serious data integrity issues. Practically the point of transactions I think.
Praesagus
+1  A: 

If your transaction is going to one database, than it's better to do transaction in stored procedure.The other way can be caused only by logistic issue (DBA don't like you, or he is on vacation). If you call different transacted sources (SQL Server and Oracle) in one transaction - than there is no choice other than do transaction in code.

+1  A: 

I would strongly recommend setting up one procedure for a page and managing all sql actions there. If there are multiple tasks to perform on the page that require multiple procedures, just have one procedure manage the other procedures. Your proceedure can always return multiple recordsets if needed.

  • You page will perform faster - not lots of data going back and forth, just one pull. All code on the sql is already compiled with executions plans.
  • You will be able to handle your errors much more efficiently - in one place as opposed to in two places - having two separate systems to decide if it's cirtical enough to fail - passing any errors back and forth to maintain your data integrity.
  • You minimize your points of failure. If the transaction is going well, but the web server hiccups, the sql server is left waiting for a response.
  • You will save tons of time troubleshooting and debugging.
  • It will help modularize your code on the sql server. You can reuse sprocs to perform like tasks and end up with a more fleixble scalable robust system. HTH
Praesagus
+1  A: 

Here are my 2 simple rules for when to use transactions:

  • if the procedure has more than one data changing statement, it will contain a transaction.
  • if the application calls more than one stored procedure that changes data, it will contain a transaction.
KM