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

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

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

Rollback Retaining [D7, IB6.x]

REA © (2006-10-12 15:28:00)
Делаю такую последовательность действий: открываю IBTable, добавляю запись, делаю Rollback Retaining. Как и ожидалось в базу запись не попадает, но в буфере компонента похоже остается. Как этого избежать? СУБД Firebird 2.

REA (2006-10-12 16:56:00) [1]
>Нет конечно. Ведь кэш находится на клиенте, и до ApplyUpdates на сервер ничего не посылается.

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

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

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

Zacho (2006-10-12 16:17:00) [3]
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 (2006-10-12 16:16:00) [4]
>С кешированными датасетами работать не сложнее, чем с обычными
срабатывают ли при этом ограничения сервера на нарушение ключей и т.п.?

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

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

Zacho (2006-10-12 16:12:00) [5]
REA (12.10.06 15:58) [9]

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

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

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

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

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

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

REA (2006-10-12 16:01:00) [7]
[8]
Спасибо, кое что уже читал. Но вопрос конкретный все же. Я думал, что может есть что то вроде AutoRefreshOnRollback. Если нет, будем вручную перечитывать.

REA (2006-10-12 15:58:00) [8]
>В смысле "таблицы" ? И зачем узнавать ?

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

Sergey13 (2006-10-12 15:57:00) [9]
> [5] REA (12.10.06 15:41)

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

Zacho (2006-10-12 15:50:00) [10]
REA (12.10.06 15:32) [2]
Тогда какой смысл в Rollback Retaining

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

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

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

Desdechado (2006-10-12 15:45:00) [11]
разница принципиальная:
1. нет нагрузки на сервер БД и траффика
2. ничего запоминать не надо, изменения кэшируются без тебя и CancelUpdates отменяет их все

REA (2006-10-12 15:41:00) [12]
Это можно, но принципиальной разницы нет с переоткрытием, а мороки больше - работать с этим сложнее, нужно запоминать что отматывать назад.

Desdechado (2006-10-12 15:37:00) [13]
логичнее не использовать Table, а использовать запрос
при этом можно вызвать CancelUpdates, тогда кэшированнные изменения отлетят в исходном направлении

REA (2006-10-12 15:34:00) [14]
Есть конечно вариант перебрать все таблицы в модуле для транзакции и те, что закрылись при Rollback переоткрыть...

REA (2006-10-12 15:32:00) [15]
Тогда какой смысл в Rollback Retaining, если переоткрывать?
И еще - как узнать на какие таблицы повлиял Rollback, чтобы их переоткрыть? (специально не запоминая где-нибудь)

Johnmen (2006-10-12 15:30:00) [16]
IBTable.Close-IBTable.Open

Наверх

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