Summary

In this chapter, we have covered quite a bit of ground in three somewhat connected areas of SQL Server stored procedure coding.

Cursors are tools for writing row-at-a-time logic in our stored procedures. We should minimize their use in T-SQL code. They are great tools if you need them, but most of the uses of cursors could easily be rewritten using user-defined functions and basic SQL code. SQL Server does a better job using these facilities than it does with cursors.

Transactions are used to give us the ability to group together multiple operations into one, in our stored procedures. When you have multiple calls, where one call must succeed for the previous calls to be valid, use a transaction. Without them, we tend to get orphaned rows in our databases that can cause the DBA a real headache.

Concurrency actually consists of a number of topics, but it boils down to managing the needs of the integrity of the data against the desire to have more than one user working on the server at one time. It is dependent on the hardware subsystems and OS, as well as SQL Server locks, and how we manage them with isolation levels. The primary thing is to keep operations short, only touching the data that is needed to solve the problem at hand.