"Transaction isolation level" mainly affects (in my understanding) the behavior of the read operation, i.e. whether a read operation will issue some locks. In the case of "read uncommitted", here is a quote from MSDN
Transactions running at the READ UNCOMMITTED level do not issue shared
locks to prevent other transactions from modifying data read by the
current transaction. READ UNCOMMITTED transactions are also not
blocked by exclusive locks that would prevent the current transaction
from reading rows that have been modified but not committed by other
So to your question, the answer is NO, the update will not be affected by "read uncommitted" transaction isolation level inside the same stored procedure.
-- Update (a sample to prove this logic)
In SSMS, we open two windows, and in Window 1 (W1 hereafter), run the following
create table dbo.t (a int)
insert into dbo.t (a) values (10)
set a = 20
where a = 10
-- commit tran
In another Window (W2), run the following (see the comments for the behavior)
set transaction isolation level read uncommitted
select * from dbo.t -- you can have dirty read, showing [a]=20, which is an uncommitted UPDATE in W1
-- the following update will wait (before proper locks are granted)
set a = 30
where a= 10
This means the UPDATE statement in W2 (with READ UNCOMMITTED) is not impacted by the transaction isolation level (i.e. still behaves as expected) as the SELECT statement.
-- UPDATE 2:
According to MSDN UPDATE t-sql,
WITH ( Table_Hint_Limited )
Specifies one or more table hints that
are allowed for a target table. The WITH keyword and the parentheses
are required. NOLOCK and READUNCOMMITTED are not allowed. For
information about table hints, see Table Hints (Transact-SQL).
So my understanding is that when you run UPDATE statement, in SQL Server, there is no way that you can update on dirty data (i.e. uncommitted data) even if you can read the dirty data in your session.