Скачать: CL | DM;

Транзакции   Найти похожие ветки 

← →
MORA   (2004-11-19 13:48) [0]

Достигнув некоторого более-менее уровня в проектировании БД и написании для них апликух, попалась мне под руку книжица для начинающих по программированию БД в Д-7. (Рекомендую всем иногда возвращаться назад - почерпнёте много интересного, но на другом уже уровне!). Дык вот. Возник у меня естественный вопрос:

При использовании кэширования в запросе Query (CachedUpdetes = True) юзверь может НАДОЛГО зависнуть над редактированием одной записи. В это же время другой юзверь, отредактировав её же, успешно сохраняет (ApplyUpdates). А первый пытается стартовать транзакцию, которая записывает в кэшированную(!?) таблицу изменения (изменения не только в эту единственную таблицу, но и в НЕКЭШИРУЕМУЮ!) - допустим успешно. А потом уже нажимает кнопку ApplyUpdates. В обработчике OnUpdateRecord например можно отказаться от сохранения изменений на диске. Но при этом всё ,что сделано в транзакции, не касающееся данной кэшируемой таблицы, останется.

Может, я неправильно организовал логику, то поправьте меня.

---

← →
msguns ©   (2004-11-19 13:55) [1]

Параметры транзакции, тип БД, движок ?

---

← →
MORA   (2004-11-19 13:57) [2]

>[1]
Пример я описал. Код неважен, выжно когда начало и Коммит/Роллбэк.
БД например IB, хотя по-моему тож неважно

---

← →
Johnmen ©   (2004-11-19 14:09) [3]

Кеширование в данном случае неважно.
Главное Коммит/Роллбэк. Перед внесением изменений в таблицы стартуешь тр., после этого Коммит/Роллбэк.

---

← →
MORA   (2004-11-19 14:35) [4]

>[3]
да. наверное так. Т.е. надо следить ,какая табл. кэшируется, а какая - нет.
Я имею в виду ситуацию, когда в транзакции изменяется и та, и другая таблицы. И здесь же нужно делать ApplyUpdates().

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

---

Страницы: 1 вся ветка

Скачать: CL | DM;



Память: 0.46 MB
Время: 0.024 c