Will transactions stop other code from reading inconsistent data?

I have a stored procedure that inserts into several tables in a single transaction. I know transactions can maintain data consistency in non-concurrent situations by allowing rollbacks after errors, power failure, etc., but if other code selects from these tables before I commit the transaction, could it possibly select inconsistent data?

Basically, can you select uncommitted transactions?

If so, then how do people typically 开发者_JAVA技巧deal with this?

---

This depends on the ISOLATION LEVEL of the read query rather than the transaction. This can be set centrally on the connection or provided in the SELECT hint.

See: Connection side: http://msdn.microsoft.com/en-us/library/system.data.isolationlevel.aspx

Database side: http://msdn.microsoft.com/en-us/library/ms173763.aspx

---

As already mentioned by Aliostad, this depends on the selected isolation level. The Wikipedia article has examples of the different common scenarios.

So yes, you can choose to get uncommitted data, but only by choice. I never did that and I have to admit that the idea seems a bit ... dangerous to me. But there are probably reasonable use cases.

---

Extending Aliostad's answer:

By default, other reading processes won't read data that is being changed (uncommitted, aka "dirty reads"). This applies to all clients and drivers

You have to override this default deliberately with the NOLOCK hint or changing isolation level to allow "dirty reads".