1-я транзакция:
begin tran
update customers set CustomerID = CustomerID where CustomerID = 'ALFKI'

2-я транзакция:
set lock_timeout 0
begin tran
update customers set CustomerID = CustomerID where CustomerID = 'ALFKI'
if @@error <> 0 begin
rollback
print '!!!'
end
else commit
set lock_timeout -1

Вообще говоря, блокировки являются внутренним механизмом сервера для обеспечения целостности данных. Если Вы хотите сами управлять ими, то это все равно, что сказать, почему я не могу, например, полностью держать под контролем план выполнения запроса? Мне не нравится план, который строит сервер, как подсунуть оптимизатору мой собственный? Существует базовый встроенный функционал как данность. Если хочется управлять абсолютно всем - проще написать свой собственный сервер.

Не нравится - не ешьте, но зачем плеваться? Да и на брудершафт мы с Вами, в общем-то, не пили.

Ну на самом деле Вы правильно сделали, что извинились, потому что рецепт Dankov'a вообще говоря не работает при всем к нему уважении. Хотел было оставить Вам эти грабли, раз Вы такой умный, но ладно уж. Вот смотрите:

1-я транзакция:
begin tran
select * from customers (holdlock)

Вы про нее ничего не знаете, поэтому сделали по данному Вам совету
2-я транзакция:
select * from customers (readpast)
Увидели, что все записи якобы свободны, обрадовались и сделали следующим шагом
update customers set customerid = customerid where customerid = 'alfki'
Ну и, естественно, попались.

В то же время, если в 1-й транзакции заменить select * from customers (holdlock) на update customers set customerid = customerid where customerid = 'alfki', то все будет работать.

Поэтому, кстати, конструкция, которую привел Jimmy, несколькими постингами выше, совершенно не аналогична моей, как он утверждает.

Мужики, я уже давно прошел тот этап, на котором хотелось раскидывать пальцы. Сейчас мне по-большому счету все равно, что вы пишете. Но вы хотя бы немного почитайте про типы блокировок и уровни транзакций, прежде чем наезжать.

Капкан в том, что как сказано в BOL, "The READPAST lock hint applies only to transactions operating at READ COMMITTED isolation and will read only past row-level locks". А holdlock, как справедливо заметил Jimmy, соответствует уровню изоляции serializable. Или можно было на read committed попробовать заблокировать таблицу или страницы, результат был бы тот же - readpast бы эти блокировки не заметил. Получается, что Вам нужно читать блокировки из sp_lock и преобразовывать file_id:page_id:row_id в конкретную запись конкретной таблицы. Или key, если запись блокирована как запись не по row_id, а по индексному ключу. А если она вообще блокирована не на уровне записи, а лежит на заблокированной странице или в таблице? Проверять все страничные и выше блокировки и смотреть, какие записи она охватывает? Меня такой способ не слишком воодушевляет. Поэтому я и утверждал, что в SQL Server не существует надежного способа контроля блокировок на низком уровне. Философия этого дела, подразумевавшаяся разработчиками, на мой взгляд, очень проста - потому что не фига туда лазить. Ну т.е. Вы можете возмущаться на меня, на Microsoft, если хотите, но таковы правила игры. Я же не возмущаюсь, что в Жигулях при желании (и умении) можно самому карбюратор перебрать, а в иномарке под капотом все запаяно так, что не подлезешь. Так что в принципе, вариант с set lock_timeout, наверное, самый простой и надежный из того, что сейчас приходит на ум.

Рискну подытожить, к чему мы пришли. Просьба не принимать за распальцовку, скорее, так - старческое брюзжание.
Первоначальная формулировка задачи являлась порочной. Определить заблокированные записи в гриде и заблокировать на время сессии остальные - этим должен заниматься сервер БД, но не клиентское приложение. Причем не важно, говорим мы о SQL Server, об Oracle или о чем-либо в том же роде. Разные уловки существуют, но они либо громоздки, либо неудобны. Единственный надежный способ узнать, заблокирована ли запись, состоит в том, чтобы попытаться заблокировать ее самому. Да и то с известными оговорками, п.ч., повторюсь, это прерогатива сервера.
Каковы типовые способы решения с поправкой на теорию? Разумеется, клиентский курсор, на котором остановился SergSuper. (Вообще, страшный человек, ибо он достиг просветления намного раньше нас и теперь может позволить снисходительно взирать на мышиную возню, к-ю мы здесь развели). Когда каждый берет копию своего куска, работает с ней локально, а потом в доли секунды делает батчевый апдейт. Коллизии практически исключены, за одним но: прежде чем аплоадить изменения на сервер, было бы полезно предварительно знать, как они там изменились, пока я их мусолил на клиенте. В ADO есть возможность сравнить значения, но это лишний roundtrip на сервер. В идеале эта задача подобна той, к-я здесь неоднократно поднималась: как в моем клиентском гриде автоматом рефрешить только те записи, которые кто-то поменял, пока я здесь их разглядывал. С недавним выходом MS SQLSrv-NS она решается элементарно.
Второй способ состоит, очевидно, в том, чтобы делать клиенту snapshot на время транзакции не на клиенте, а на сервере. Ну т.е. вы эту картинку сняли и с ней работаете, не беспокоясь за то, что с этими данными делают остальные. (Пока не придет время закоммитить изменения - на этот счет сущ-т встроенные или пользовательские разрешители конфликтов). Это то, что умеет сейчас Oracle, но не умеет SQL Server. Мне недавно приснился вещий сон, будто в Yukon это будет. Я, правда, не досмотрел, как это реализовано. Все-таки сегментов отката в SQL Server нет, а Transaction Log - это redo-log в классическом понимании. Если бы мне приснилось, что они и before-триггеры сделают, тогда это бы точно означало, что в Юконе меняется модель журналирования. А так - не знаю, скоро увидим.

Notification Services. Поговаривают, что они войдут в Юкон на правах штатной ф-ти.

Ну нет, нет. Категорически не согласен. А как же .NET Alerts? Пожалуй, в чем Вы правы - это необходим хороший брокер, дабы не привязывать все ручками. Но это вопрос ближайшего времени, я полагаю. Ибо если MS проталкивает Юконовский сторидж на уровень ядра ОС ( как нам обещает компьютерная пресса ), то по идее каждое окно в размазанной по многим серверам Windows должно в будущем получать сообщение по этому механизму. Вообще получается чертовски интересная по замыслу вещь. М.б. вынесем обсуждение SQL-NS в отдельную ветку?

Бр-р. Это хороший вопрос. Давайте посчитаем. Значит, SQL Server 6.5 вышел, дай Бог памяти, в апреле 96 г. Семерку они переписали, почитай, заново, и выпустили в декабре 98 г., т.е. через 2 г. 8 мес. Yukon, судя по тому, что туда закладывают, будет им стоить примерно столько же, если не больше. Положим, 3 года. Отсчитываем этот период от даты выхода SQL Server 2000 - получаем (плюс/минус) сентябрь 2003. Это значит, что, если ничего не случится, 1-ю бету они должны выпустить в конце этого / начале след.года. Ну а поскольку, как каждый наверняка убедился на собственном опыте, сроки проектов сдвигаются скорее в плюс, чем в минус, то это скорее январь 2003, чем декабрь 2002. Примем во внимание, что во времена семерки они отвлекались только на сервис-паки к 6.х, а сейчас они параллельно пишут и SQL Server CE 2.0, и 64-битный SQL Server 2000. Получается февраль-март 2003 г.