When to use Transactions in SQL Server

You use transactions when the set of database operations you are making needs to be atomic.

That is - they all need to succeed or fail. Nothing in between.

Transactions are to be used to ensure that the database is always in a consistent state.

In general, unless there is a good reason not to use them (long running process for instance), use them. See this blog post for details.

---

Try/Catch blocks have nothing to do with transactions - they are used for exception handling. The two concepts are not related and are not replacements for each other.

The common answer is that transactions allow database operations to be atomic. The confusion is in what this means. It's not about the particular operations involved whether they are SELECT, UPDATE, DELETE, etc. It's about the semantic meaning of the data itself. From the viewpoint of the operations, from the bottom-up, we say that as a group, they are atomic. But, from the abstract level, looking from the top-down, we say we have conservation of information.

An easy example would be if you had 2 accounts and you did not want money to be created nor destroyed in the transfer between them. Another, more subtle example, would be if you had a group of data that needed to be either created or destroyed as a group. In other words, having partial information doesn't make sense. I guess an example might be if you had a user and wanted to always guarantee they had a first and last name. Not a partial name.

With that said, people come up with phrases and rules of thumb to express what atomic means, such as "the operations all need to succeed or fail". Also, people tend to notice patterns, such as a SELECT would not need a transaction.