Louder Спасибо большое, помогло!
Единственный минус такого решения - то что в каждый селект придется дописать фразу "WITH (NOLOCK)".
Хочу вас огорчить, это не единственный минус данного решения, и при том не самый большой.
Вот что в статье Locking Hints в BOL про него пишут:
Do not issue shared locks and do not honor exclusive locks. When this option is in effect, it is possible to read an uncommitted transaction or a set of pages that are rolled back in the middle of a read . Dirty reads are possible. Only applies to the SELECT statement.

Да, вот еще кусочек из BOL из статьи Declare Cursor

OPTIMISTIC

Specifies that positioned updates or deletes made through the cursor do not succeed if the row has been updated since it was read into the cursor. SQL Server does not lock rows as they are read into the cursor . It instead uses comparisons of timestamp column values, or a checksum value if the table has no timestamp column, to determine whether the row was modified after it was read into the cursor. If the row was modified, the attempted positioned update or delete fails. OPTIMISTIC cannot be specified if FAST_FORWARD is also specified

Ну там и еще есть что почитать..

авторКонечно не красиво всё это, но лучшего решения всё равно нет.

Ну так можно же добиться, чтобы курсор не блокировал данные и без грязного чтения.
авторКачать пару миллионов записей на клиента тоже не выход...
А каким образом у вас выборка оказалась на несколько миллионов записей? Как тогда по ней навигация происходит? Может следует подумать о том, чтобы добавить пару условий в WHERE?

авторКак добиться? PB сам генерит курсор, я же никак на это повлиять не могу :(
Погодите, по-моему вы вводите меня в заблуждение. PB никакой курсор не генерирует, он просто отправляет запрос, и докачивает выборку по мере надобности. По крайней мере так все выглядит в Profiler'е. Если бы он действительно делал курсор, его можно было бы на SQLPreview перехватить и подкорректировать.
Отсюда еще одна идея - сделать курсор самому и самому его докачивать, по мере необходимости.

авторДа даже если не на несколько миллионов, а на пару тысяч - нехорошо качать на клиент все записи сразу.
Если вся выборка на клиенте, то с ней легче работать - искать, фильтровать, ScrollBar отображать :). Так что порядка 1000 записей можно подумать чтобы и откачать. Выбор подхода сильно зависит от количиства пользователей и скорости передачи данных. Другое дело, что интерфейс надо проектировать, чтобы записи десятками тысяч не сыпались на клиента. Ну что он с такой выборкой потом делать будет?