Я все-таки настоятельно призываю изучать наследие классиков.
Из статьи "Microsoft SQL Server 7.0 - контрольная по безопасности":

В. К вам пришел продвинутый пользователь Саша, прослышавший про то, что в SQL Server 7.0 есть блокировки уровня записи, и в ультимативной форме потребовал, чтобы ему выдали на них права, потому что когда он на одном соединении делает
begin tran
update Auth with (rowlock) set au_lname = au_lname where au_id = '172-32-1176',
а на другом
select * from auth where au_id = '213-46-8915',
второй запрос подвисает, пока на первом соединении не сказать commit tran или rollback. Отсюда, по мысли Саши, неопровержимо следует, что SQL Server все равно блокирует не запись, а страницу несмотря на явный хинт. Ваши действия: а) grant rowlock on Auth to [Саша]; б) sp_addrolemember ‘db_lockadmins’, ‘Саша’; в) стартовать SQL Mail под профилем администратора и предложить Саше отправить сообщение c описанием проблемы, начинающееся словами «Дорогой SQL Server...»; г) create index auth_ix on Auth(au_id)?
О. г). Задача не имеет отношения к теме безопасности, так как блокировки являются внутренними объектами SQL Server и понятие прав пользователей для них не существует. После того, как проверены права пользователя на операцию, в ходе ее выполнения блокировки накладываются автоматически. В данном случае первый процесс действительно блокировал только одну запись (см. sp_lock), второй же останавливался из-за того, что не мог прочитать из нее поле au_id и проверить условие where для этой записи. После создания индекса он станет брать au_id из индексных страниц.

"Во-первых, не понял при чем здесь права пользователей"
Во-первых, права пользователей здесь при том, что статья д-но была посвящена безоп-ти. А поск. в отл. от авторов толстых книг я не пересказываю BOL, а беру реальные ситуации, то в моей прошлой жизни такой случай реально имел место. Т.е. пришел один перец, типа продвинутый юзер, и пытался продемонстрировать свои познания, полученные после прочтения толстой книги.
"Я отличаюсь от Саши тем, что ..."
Во-вторых. Не надо искать в моих словах параллели. Статья написана полтора года назад, и я не хотел совпадениями задеть кого-л. из присутствующих здесь сейчас.
"Второе, уровень изоляции транзакции - нулевой, а следовательно данные из таблицы должны читаться свободно."
В-третьих, не надо быть американским стюдентом. Стоит иногда давать себе труд подумать самому. Напр., почему работает вот так:
1-я сессия:
set transaction isolation level read uncommitted
begin tran
update Auth with (rowlock) set au_lname = au_lname where au_id = '172-32-1176'
2-я сессия:
set transaction isolation level read uncommitted
select * from auth where au_id = '213-46-8915'
и не работает, если на 2-м коннекте вместо select поставить update Auth with (rowlock) set au_lname = au_lname where au_id = '213-46-8915'
PS. AlexeyVG прав. Прочтите еще раз опр-е "грязного чтения".

PPS. set transaction isolation level в 1-ю сессию попал случайно. Сов.очев., что он там не нужен.