Rollback Retaining

← →
REA (2006-10-12 15:28) [0]

Делаю такую последовательность действий: открываю IBTable, добавляю запись, делаю Rollback Retaining. Как и ожидалось в базу запись не попадает, но в буфере компонента похоже остается. Как этого избежать? СУБД Firebird 2.

← →
Johnmen © (2006-10-12 15:30) [1]

IBTable.Close-IBTable.Open

← →
REA (2006-10-12 15:32) [2]

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

← →
REA (2006-10-12 15:34) [3]

Есть конечно вариант перебрать все таблицы в модуле для транзакции и те, что закрылись при Rollback переоткрыть...

← →
Desdechado © (2006-10-12 15:37) [4]

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

← →
REA (2006-10-12 15:41) [5]

Это можно, но принципиальной разницы нет с переоткрытием, а мороки больше - работать с этим сложнее, нужно запоминать что отматывать назад.

← →
Desdechado © (2006-10-12 15:45) [6]

разница принципиальная:
1. нет нагрузки на сервер БД и траффика
2. ничего запоминать не надо, изменения кэшируются без тебя и CancelUpdates отменяет их все

← →
Zacho © (2006-10-12 15:50) [7]

REA (12.10.06 15:32) [2]
Тогда какой смысл в Rollback Retaining

А какой тебе нужен ?
RollbackRetaining - это прктически то же самое, что откат транзакции и немедленный её старт с теми же параметрами и без закрытия курсоров. Вот и думай, какой смысл в этом в твоей задаче.

> как узнать на какие таблицы повлиял Rollback

В смысле "таблицы" ? И зачем узнавать ?

← →
Sergey13 © (2006-10-12 15:57) [8]

> [5] REA (12.10.06 15:41)

http://ibase.ru/develop.htm
Читай все, особенно про транзакции.

← →
REA (2006-10-12 15:58) [9]

>В смысле "таблицы" ? И зачем узнавать ?

Dataset-ов вообще то много и действий с ними в пределах транзакции тоже.
Задача отмотать все в исходное состояние как до запуска транзакции.
Что то мне подсказывает, что с кэшированными таблицами будет непросто работать, поэтому сделал RollbackRetaining и Close-Open для всех DataSet, которые потенциально могли модифицироваться.

← →
REA (2006-10-12 16:01) [10]

[8]
Спасибо, кое что уже читал. Но вопрос конкретный все же. Я думал, что может есть что то вроде AutoRefreshOnRollback. Если нет, будем вручную перечитывать.

← →
REA (2006-10-12 16:11) [11]

Вот еще вычитал:
Не рекомендуется слишком часто завершать одну и ту же транзакцию по retaining, или производить в каждом таком "интервале" много изменений - это чревато появлением ошибки 287 "too many savepoints" в interbase.log. (о механизме savepoints читайте в статье). Кроме того, транзакция, завершаемая по CommitRetaining, с точки зрения сервера и сборки мусора выглядит как длительно работающая транзакция SNAPSHOT (то есть, CommitRetaining в этом плане не является аналогом Commit). А это значит, что CommitRetaining фактически препятствует сборке мусора, независимо от типа транзакции - Snapshot или ReadCommitted.

Т.е. плюсы Retaining компенсируются ее же минусами. Какие будут соображения на этот счет?

REA (12.10.06 15:58) [9]

1. С кешированными датасетами работать не сложнее, чем с обычными. Другое дело, что вразных версиях IBX были различные баги в CachedUpdates. Как с этим в текущей версии - не знаю, может уже всё нормально.

2. Всё-таки под "таблицами" ты имел в виду датасеты в приложении ? Ну так бы сразу и сказал.

> Задача отмотать все в исходное состояние как до
> запуска транзакции.

Для этой цели CachedUpdates гораздо проще.

← →
REA (2006-10-12 16:16) [13]

>С кешированными датасетами работать не сложнее, чем с обычными
срабатывают ли при этом ограничения сервера на нарушение ключей и т.п.?

>Всё-таки под "таблицами" ты имел в виду датасеты в приложении
Есть и IBTable и IBDataSet сейчас. Пока что полностью от IBTable не отказался, хотя проблем с ним возникает больше.

Придется наверно открывать таблицу, поработать, закрыть. При необходимости переоткрыть. В принципе оно и логично.

REA (12.10.06 16:11) [11]
это чревато появлением ошибки 287 "too many savepoints" в interbase.log

Забудь. Это было актуально для каких-то древних версий IB (насколько помню, до 6.0)

> Кроме того, транзакция, завершаемая по
> CommitRetaining, с точки зрения сервера и сборки
> мусора выглядит как длительно работающая транзакция
> SNAPSHOT

Не уверен, но это тоже могло уже устареть. Спроси в news://news.gmane.org/gmane.comp.db.firebird.russian

REA (12.10.06 16:16) [13]
срабатывают ли при этом ограничения сервера на нарушение ключей и т.п.?

Нет конечно. Ведь кэш находится на клиенте, и до ApplyUpdates на сервер ничего не посылается.

← →
REA (2006-10-12 16:56) [16]

>Нет конечно. Ведь кэш находится на клиенте, и до ApplyUpdates на сервер ничего не посылается.

Вот и я о том же.
Вобщем как то выкрутился. Больше писанины, но может оно и к лучшему.

Rollback Retaining Найти похожие ветки