Posted by Greg D. Moore \(Strider\) on 04/23/07 14:38

"Igor" <jerosimic@gmail.com> wrote in message
news:1177332206.775022.264630@b58g2000hsg.googlegroups.com...
> 1. In this topic
> http://groups.google.com/group/comp.databases.ms-sqlserver/browse_thread/thread/b4a07b516f4a2fcd/cb21516252b65e7c?lnk=gst&q=SET+TRANSACTION+ISOLATION+LEVEL+READ+UNCOMMITTED&rnum=10#cb21516252b65e7c,
> someone wrote: "I've implemented SET TRANSACTION ISOLATION LEVEL READ
> UNCOMMITTED at the beginning
> of a number of stored procedures and, then SET TRANSACTION ISOLATION
> LEVEL READ
> COMMITTED at the end to minimize the disruption to the application.".
> My question is, do you really need to set READ COMMITTED at the end of
> stored procedure? What scope does that command affect?

I believe the READ COMMITTED is pointless there.


>
> 2. Could someone write some real world example where i should never
> read uncommitted data... i'm having trouble understanding when i
> should and when i should not use it.
>

It depends. If you don't mind showing possibly inaccurate information
faster, then READ UNCOMMITTED may be for you.

In some cases, this is fine. HOWEVER, in many others not only is it not
fine, it's downright wrong.

For example if you're writing say a banking application, the user would
NEVER want to see "wrong data".

(for example only partially posted transactions, phantom ones, etc.)



--
Greg Moore
SQL Server DBA Consulting Remote and Onsite available!
Email: sql (at) greenms.com http://www.greenms.com/sqlserver.html

[Back to original message]