vill_agerучусь, можно сказать (выбираюсь из Foxpro :)Быстрее переходите на нормальные СУБД ;)

vill_agerв моем представлении update без проблем увеличит количество зарезервированного товара
но ответа на вопрос - есть ли товар в наличии? - он не даетНа этом update может триггер висеть, который выдаст ошибку при отсутствии товара в наличии. Вообще, это может быть и не update а более сложная хранимая процедура. Важно, чтобы она исполнялась в транзакции с правильным уровнем изоляции. Т.е. последовательность такая:

запуск транзакции
резервирование (при этом триггер проверяет, есть ли остаток, и ни в коем случае не проверяйте остаток селектом)
фиксация транзакции

Если на каком-то этапе произошла ошибка, то транзакция просто откатывается

vill_agerеще раз пример:
одна единица товара, трое операторов увидели на экране остаток, и подтвердили расход
что получится?
Стартуют три транзакции. При выполнении update сервер автоматом ставит неразделяемую блокировку на запись. Соответственно, только одна из транзакций сможет выполнить этот update. Остальные засыпают. Та транзакция, которой повезло, делает коммит и сообщает об этом счастливому юзеру. В этот момент сервер автоматом снимает с записи блокировку. Просыпаются обе ожидающие ее транзакции. Пытаются сделать update. Та которой повезло больше, его выполняет, что приводит к простановке блокировки. Третья транзакция снова засыпает. Но тут срабатывает триггер, который говорит, что на складе уже ноль и отрицательным остаток быть не может. Ошибка возвращается юзеру и транзакция откатывается. В момент отката (как и при коммите) автоматом снимаются все проставленные транзакцией блокировки. Тут просыпается третья транзакция, пытается сделать update, но триггер не спит и выдает ошибку. Третий юзер тоже получает откат транзакции.

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

А вообще, запустите на компе три консоли, настройте их, чтобы они не делали автокоммит после выполнения каждой команды, стартуйте вручную транзакции и выполните апдейт одной и той-же записи из разных консолей. Вы увидете блокировки в действии. Выполните в одной консоли коммит или роллбак. Вы увидите снятие блокировок в действии. Поиграйтесь с констрейнами уникальности по полю: создайте таблицу, в которой есть уникальный ключ. Из одной консоли вставьте запись, потом из другой консоли попробуйте вставить запись с таким-же ключем. Думаете, сервер должен выдать ошибку? Он не может... Он просто заблокирует вторую транзакцию, т.к. не знает, что делать. Если первая консоль транзакцию откатит, тогда вторая сможет выполнить операцию. Если первая консоль транзакцию коммитит, тогда вторая должна выдать сообщение об ошибке дублирования ключей.

Забывайте про свой Foxpro и добро пожаловать в мир декларативного описания целостности данных и автоматической поддержки транзакций в разных режимах изолированности.

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

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