Managing Transactions in SQL Server Stored Procedures   03 Aug 2005 00:00 GMT

Last week's article, Maintaining Database Consistency with Transactions, looked at what, exactly, transactions are and how they can be used to guarantee consistency in a database when issuing commands that modify multiple tables. Specifically, transactions ensure that a set of modifying statements are atomic, namely that either all steps succeed or all steps fail. Transactions guarantee atomicity across query errors - such as trying to delete a record that cannot be deleted due to a foreign key constraint, or attempting to insert a string value into a numeric field in a database table - as well as catastrophic errors, such as power failures, hard drive crashes, and so on. In short, when wrapping multiple modifying commands within a transaction the database is guaranteed to be in one of two states: either the state before the batch of commands was issued, or the state after all commands have completed - in other words, there's no 'in-between' state.

The canonical transaction example is transferring money from one bank account to another. This process involves two steps: debiting money from one account and then crediting it to the other account. What is vital to avoid is having only the first step complete but, perhaps due to a power failure, the second not completing. When moving funds we don't want the bank to debit money from our account if they're not going to credit it back to another.

In addition to discussing the purpose of transactions, last week's article also examined how to wrap multiple modifying statements within a transaction using ADO.NET. In particular we looked at using the SqlTransaction and SqlConnection classes. A transaction is started with a call to the SqlConnection class's BeginTransaction() method (which returns a SqlTransaction object) and can be committed or rolled back via the SqlTransaction object's Commit() and Rollback() methods.

In this week's article we'll continue our look at transactions, examining how to create, commit, and rollback transactions strictly through stored procedures. After examining the T-SQL syntax for working with transactions we'll discuss when one would opt to use transactions directly in stored procedures versus using them in the ADO.NET layer. Read on to learn more!
Read More >

Source: 4GuysFromRolla

Register for the Microsoft Professional Developers Conference 2005   02 Aug 2005 21:24 GMT
Join developers at the Microsoft Professional Developers Conference 2005, where the next waves of Microsoft Windows and Microsoft Office System developer capabilities will be unveiled.
Source: MSDN

Review: Beginning ASP.NET 2.0 Databases Beta Preview   02 Aug 2005 00:00 GMT
This article provides a brief review of the latest book from Wrox publishing, titled Beginning ASP.NET 2.0 Databases Beta Preview.
Source: AspAlliance

The Baker's Dozen: 13 Productivity Tips for Building a .NET Distributed Application   01 Aug 2005 23:42 GMT
The Common Ground Framework for .NET provides a set of starter classes for building database applications in a distributed environment.
Source: DevX

Calling Web Services Asynchronously   01 Aug 2005 04:00 GMT
Making synchronous calls to web services can be problematic on occasion, because they have the potential to cause considerable delay. The reason for this is the manner in which synchronous calls work: the application blocks the client until the web service call returns. To overcome the necessity of having to wait for the web service response, we can call web services asynchronously. Raj Makkapati walks you through how to call web services asynchronously.
Source: O'Reilly