Блокирование строки таблицы на время редактирования

← →
STX (2006-07-17 15:02) [0]

Добрый день.

FIBPlus + Firebird 2.0

При вызове FIBDataSet.edit, текущая запись автоматом блокируется (poProtectedEdit) от редактирования др. пользователями на время работы транзакции. Но, насколько я знаю такая транзакция нежелательна, т.к. может оказаться слишко длительной.

Я решил использовать для INSERT, UPDATE, DELETE - хранимые процедуры. Но вот проблема - не могу понять как в данном случае заблокировать запись. Ведь пока юзер редактирует значения, кто-нить может вообще удалить запись.

← →
StriderMan © (2006-07-17 15:08) [1]

можно сделать

UPDATE ТАБЛИЦА SET ПОЛЕ = ПОЛЕ WHERE ID = ЗНАЧЕНИЕ

и не делать Transaction.Commit..

← →
STX (2006-07-17 15:10) [2]

Да, но тогда транзакция опять может оказаться активной на длительное время.

← →
DrPass © (2006-07-17 15:12) [3]

> Но, насколько я знаю такая транзакция нежелательна, т.к.
> может оказаться слишко длительной.

А какие у тебя еще есть варианты? Ты ж не всю таблицу блокируешь

← →
DrPass © (2006-07-17 15:12) [4]

...я надеюсь :)

← →
StriderMan © (2006-07-17 15:19) [5]

..пришло на ум:

сделать триггер, который будет подтягивает ключевое поле строки из какой-нибудь вспомогательной таблички типа LOCKLIST. Соответственно при INSERT"е UPDATE"е и DELETE будет проверяться не изменяется ли строка, которая заблокирована.
Или я велосипед изобретаю? может такое уже есть?

← →
STX (2006-07-17 15:22) [6]

> StriderMan © (17.07.06 15:19) [5]
> ..пришло на ум:

------> вилосипед :)
---------------------------------------

← →
DrPass © (2006-07-17 15:22) [7]

> StriderMan © (17.07.06 15:19) [5]

А смысл? Стандартная транзакция read_commited + rec_version, и больше ничего не нужно

← →
StriderMan © (2006-07-17 15:24) [8]

> DrPass © (17.07.06 15:22) [7]
> А смысл? Стандартная транзакция read_commited + rec_version,
> и больше ничего не нужно

понятное дело, я и сам так делаю всегда. А вот автору ветки не нравится...

← →
STX (2006-07-17 15:28) [9]

Параметры транзакции
write nowait rec_version read_committed

> понятное дело, я и сам так делаю всегда. А вот автору ветки
> не нравится...

Например: Если два пользователя одновременно решили отредактировать одну и туже строку. 1-й изменил+подтвердил. 2-й редактирует уже старые записи, +подтвердил = может получится косяк в НД

> Если два пользователя одновременно решили отредактировать
> одну и туже строку. 1-й изменил+подтвердил

Первый начал изменять, залочил запись. Второй ждет. Первый подтвердил, послал event, второй обновил у себя и меняет что ему нужно

> [9] STX (17.07.06 15:28)
> Например: Если два пользователя одновременно решили отредактировать
> одну и туже строку. 1-й изменил+подтвердил. 2-й редактирует
> уже старые записи, +подтвердил = может получится косяк в
> НД

Если 2 юзера одновременно вручную редактируют одну запись - это скорее всего, ИМХО, недоработка проектирования + плохая организация труда в конторе. Подобные изменения (например обновление наличия товара на складе) желательно делать короткими транзакциями, не зависящими от медлительности юзера (например через тригер).

> Если 2 юзера одновременно вручную редактируют одну запись
Поддерживаю. Это называется "бардак". Как в организации труда, так и в головах.
Не, конечно, такие ситуации бывают, но это нетипичная ситуация. По моим прикидкам, не более 5%.

Блокирование строки таблицы на время редактирования Найти похожие ветки