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

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

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

Транзакция на обновление записи [D7, FB 2.0]

RomanH © (2006-10-31 12:20:00)
Мастера, и снова я к Вам, за вашей помощью. Существует таблица, в которой находится список и колличество товара для продажи клиентам. При выборе какой нибудь записи, появляется модальное окно для выбора колличества товара(т.е. у пользователя А стартует транзакция с параметрами {write,concurrency,nowait}).После выбора колличества, создаю накладную, а в основном списке уменьшаю колличество, подтверждаю транзакцию.В это же время пользователь B тоже хочет продать этот же товар но возникает ошибка deadlock update conflict.Помогите пожайлусто, как сделать чтобы два пользователя могли продавать(в моем случае редактировать т.е. уменьшать колличество в основной таблице)

atruhin (2006-11-01 16:56:00) [1]
Ну никто и не спорит. Просто нам так удобнее. А дыр у FB, к сожалению, пока достаточно,
что бы при желании вывести из строя БД, не зависимо от прав.
Тем более, о тригерах на основные таблицы, копий не мало ломано, иногда удобно, изменить значение
в таблице, зная что это больше ни чего не затронет.

Anatoly Podgoretsky (2006-11-01 16:20:00) [2]
> atruhin (01.11.2006 15:34:18) [18]

А у нас помешает даже при наличии этого пароля.

atruhin (2006-11-01 15:34:00) [3]
> [17] Anatoly Podgoretsky © (01.11.06 15:28)
то кто мешает мне альтернативными методами изменить запись в обход

У нас ни кто не помешает, при наличии пароля владельца БД или SYSDBA. А для остальных, модифицируемые представления,
с соответствующими тригерами.

Anatoly Podgoretsky (2006-11-01 15:28:00) [4]
> atruhin (01.11.2006 15:22:16) [16]

Может быть, но это 4 выше и возможно не к этому случаю.
Если подобное не сделано указаными способами, то кто мешает мне
альтернативными методами изменить запись в обход.

atruhin (2006-11-01 15:22:00) [5]
> Если сделано на уровне триггеров/процедур то нормально.

Ну а как же еще? Именно об этом я и написал автору 4-мя постами выше.

Anatoly Podgoretsky (2006-11-01 15:08:00) [6]
> atruhin (01.11.2006 14:58:14) [14]

Если сделано на уровне триггеров/процедур то нормально.

atruhin (2006-11-01 14:58:00) [7]
> [13] PEAKTOP © (01.11.06 13:50)

Ну это обычная практика, только у нас например, > добавляю поле FLAG_COMMIT
может иметь значения:
0 - удален
1 - в работе (не закончен)
2 - документ набран (готов)
3 - проведен
4 - закрыт (гл. бухгатер, руководитьель закрыл период, ни кто не может изменить.

PEAKTOP (2006-11-01 13:50:00) [8]
Я обычно в таких случаях в журнале документов (таблице, где хранится "шапочная" часть документа) добавляю поле FLAG_COMMIT. Пользователи могут колотить накладные хоть до посинения, фактическое списание товара происходит в момент проведенения (установки FLAG_COMMIT= 1), а возврат "на место" в момент распроведения (установки FLAG_COMMIT= 0), причем все происходит в триггерах на BEFORE UPDATE.
Таким образом, если кто-то провел накладную на доли секунды раньше, то второй при недостатке товара получит облом при проведении. А там пусть сами (пользователи) между собой разбираются, кому товар нужнее.
Таким же образом решается проблема, когда нужно наколотить накладную "в прок". Т.е. клиент по телефону заказывает товар, а оплачивать/получать придет через час. И по бизнес логике предприятия, отпускать товар нужно в момент оплаты/получения. Если его к тому моменту не оказалось в наличии, то уж извините, не успели.

atruhin (2006-11-01 12:38:00) [9]
> После выбора колличества, создаю накладную, а в основном
> списке уменьшаю колличество, подтверждаю транзакцию.В это
> же время пользователь B тоже хочет продать этот же товар
> но возникает ошибка deadlock update conflict.

Тут еще и методологически не правильно, представь, пользователь выбрал товар, ту уменьшил его кол-во на складе (основной список),
а дальше произошел сбой сети, или компьютер вырубили. Что будет, со склада ты товар списал, а куда?
Изучай теорию построения учетных систем. Статей море.

Дмитрий Белькевич (2006-11-01 03:09:00) [10]
>на ib/fb с транзакциями обычно работают так:
все чтение один через транзакцию с параметрами
Обычно она открывается при старте приложения и закрывается при его завершении.
для записи используется __максимально короткая__ транзакция
При такой работе update conflict практически невозможен.

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

RomanH (2006-10-31 16:02:00) [11]

> Anatoly Podgoretsky ©

Да нет это не обида. Просто очень хочется такую информацию чтобы было понятно все о транзакциях, хотя Дмитрий Кузьменко(ibase.ru) и описывает подробно о транзакциях все же некоторые аспекты непонятны. Наверное понимание прийдет с опытом.Сегодня транзакция на обновление записей,завтра на чтение. Надеюсь этот форум мне всегда поможет.

> Sergey13 © (31.10.06 13:35) [7]

Да как раз [1]+[3] и разрешили мою проблему сегодня.

Всем спасибо

Johnmen (2006-10-31 15:39:00) [12]

> RomanH © (31.10.06 13:20) [6]
> ...даже скачал весь сайт.

Судя по вопросу, осталось прочитать. Хотя бы основы.

Anatoly Podgoretsky (2006-10-31 15:34:00) [13]
> RomanH (31.10.2006 13:20:06) [6]

> отправляет меня на меня на IBase.ru

С каких пор отправление в правильном направлении стало обидой?

Sergey13 (2006-10-31 13:35:00) [14]
> Может существует наработанная практика по работе с транзакциями.

А чем [1] + [3] не устраивает?

RomanH (2006-10-31 13:20:00) [15]
Ну вот один из моих основных преподавателей Desdechado (это не лесть-это правда) отправляет меня на IBase.ru/Хотя там я уже можно сказать прописан, даже скачал весь сайт.
Ну ладно буду читать до прояснения(сколько же времени это займет).
Может существует наработанная практика по работе с транзакциями. Спасибо всем.

Desdechado (2006-10-31 13:10:00) [16]
читать доки и ibase.ru до прояснения

> а где жевозможность писать поддвержденные данные
Орех!
Как ты себе представляешь запись неподтвержденных данных?

ЗЫ про дедлоки тоже читать там же
они возникают, когда в разных режимах пытаешься писать данные в разном порядке, что вызывает конфликт при использовании этих режимов в разных подключениях

RomanH (2006-10-31 13:04:00) [17]

> jack128 ©

Выше указанный код :
write
read_committed
rec_version
nowaitмне все объяснил я увидел слово write.
Хотя и без параметра write работает, почему? мы же только считываем подтвержденные записи(read_committed).Объсните мнe пожайлусто
.

jack128 (2006-10-31 12:50:00) [18]
на ib/fb с транзакциями обычно работают так:
все чтение один через транзакцию с параметрами
read_committed
rec_version
nowait
read
Обычно она открывается при старте приложения и закрывается при его завершении.

для записи используется __максимально короткая__ транзакция
write
read_committed
rec_version
nowait
открыл эту транзакцию, выполнил запрос, тут же закрыл её. Никаких открытий write транзакций при открытии модального диалога быть не должно!!!

При такой работе update conflict практически невозможен.

RomanH © (31.10.06 12:41) [2]
а где жевозможность писать поддвержденные данные.
не очень понятно, что имеется в виду?

unknown (2006-10-31 12:41:00) [19]

> RomanH © (31.10.06 12:20)
> модальное окно для выбора колличества товара(т.е. у пользователя А стартует транзакция

Вот тут неправильно.
В таких случаях лучше всего сделать так:
1) Показываем форму, юзер заполняет на форме поля
2) Формируем запрос, далее starttransaction; execsql; commit;
Можно в принципе и уровень изоляции поменять.

RomanH (2006-10-31 12:41:00) [20]
Мастера ну вот получилось, с такими параметрами
read_committed
rec_version
nowait
Но так как я начинающий все таки хотелось чтобы вы меня поправили.
Read_committed-Возможность читать подтвержденные данные других транзакций.Вопрос а где жевозможность писать поддвержденные данные.

Наверх

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