Такие вещи обеспечиваются уровнями изоляций транзакций. Почитать что это такое можно здесь и здесь .

Так же неплохо почитать в BOL по секции FROM по хинтам выборочной установки уровней изоляций на таблицы, реализуемый ключевым словом WITH (уровень изоляции).

--
www.rusug.ru - портал русскоязычной группы пользователей Sybase

Да - но не все данные Test, а только попадающие под условие Value=2, то есть до момента завершения транзакции (COMMIT или ROLLBACK) в таблице Test окажутся заблокированными от изменения записи с кодом 2 и 3. Однако есть еще пара важных моментов, которые стоит обязательно помнить:
1. Так как в процедуре нет оператора завершения транзакции, то например после ее выполнения в том же ISQL данные будут блокированы далее до тех пор, пока сессия не соизволит сказать COMMIT, ROLLBACK или отсоединится (что будет означать ROLLBACK).
2. Всегда стоит разделять shared и exclusive блокироки. Так в процедуре через SELECT мы вешаем shared блокировки, таким образом блокируя писателей на эти записи, но не мешая читателям их читать, а проводя обновление UPDATE мы вешаем exclusive блокировки, таким образом запрещая доступ к данным записям как писателям, так и читателям.
3. Всегда стоит помнить про фантомы, что очень актуально при расчете остатков. Например посредством REPETABLEREAD мы гарантировали, что обрабатываемые записи никем не могут быть изменены. Однако ... если по логике задачи в таблицу разрешаются вставки в таблицу, то здесь этот уровень изоляции не подойдет. Наглядный пример - пока выполняется SELECT в процедуре, другой сессией вставляется и коммитится новая запись с Value2 = 2. Таким образом она не будет учтена в процедуре и в задаче расчетов остатков это приведет к тому, что остаток будет несоотвествовать записям в таблице. Именно по этому, для таких критических вещей уже требуется высший уровень изоляции SERIALIZABLE, который гарантирует не только защиту от изменений существующих записей, но и что никто не добавит новые записи, которые могли бы попасть под условия фильтра необходимых для обработки данных, то есть появлению фантомов. Здесь конечно чтобы не просела производительность параллейной работы множества сессий, будет необходимо тщательно продумать всю логику работы в соответствие с рекомендациями, которые я привел в тех статьях.

P.S. А вообще уровни изоляций и блокировки эта сила и скорость ... если только уметь их правильно готовить, понимать как это работает и где и как этим пользоваться, ну и использовать весь набор сапера-блокировочника - по назначению времянки, timestamp поля и прочее