Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

STX © (2006-07-17 15:02:00)
Добрый день.

FIBPlus + Firebird 2.0

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

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

Desdechado (2006-07-17 16:52:00) [1]
> Если 2 юзера одновременно вручную редактируют одну запись
Поддерживаю. Это называется "бардак". Как в организации труда, так и в головах.
Не, конечно, такие ситуации бывают, но это нетипичная ситуация. По моим прикидкам, не более 5%.

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

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

DrPass (2006-07-17 15:53:00) [3]

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

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

STX (2006-07-17 15:28:00) [4]
Параметры транзакции
write nowait rec_version read_committed

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

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

StriderMan (2006-07-17 15:24:00) [5]

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

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

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

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

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

DrPass (2006-07-17 15:22:00) [7]

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

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

StriderMan (2006-07-17 15:19:00) [8]
..пришло на ум:

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

DrPass (2006-07-17 15:12:00) [9]

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

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

DrPass (2006-07-17 15:12:00) [10]
...я надеюсь :)

STX (2006-07-17 15:10:00) [11]
Да, но тогда транзакция опять может оказаться активной на длительное время.

StriderMan (2006-07-17 15:08:00) [12]
можно сделать

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

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

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »