Согласен не сказал, что внешние таблицы вне транзакции, но заметьте, там было написано "... для логирования действий ..." а не для репликации, а в некоторых случаях нужно именно все действия логировать, даже те, которые отменились. Все зависит от логики приложения.Merlin писал(а):Внимание, вопрос. Що будем делать с этой записью в external table в случае ежели за оным update последовал rollback транзакции, в которой он выполнялся?
ПодгоняюAndrew Kruchinin писал(а):Я что-то не догнал наверное? After Insert/Update/Delete и какая речь об откатах?
Код: Выделить всё
Start transaction
before insert table1
insert into table1
after insert table1
before insert table2
insert into table2
after insert table2
Commit transaction или Rollback transactionВообще-то все делается гораздо проще:Klyk писал(а):На самом деле зачем это всё надо.
Есть 2 БД, связь между которыми - невозможна, следовательно репликатор неподходит. А изменения в одной БД надо отображать в другой. Есть возможность передачи только текстовых файлов (раз в сутки).
Вот я и думал создавать SQL скрипты при изменении данных в одной БД и выполнять этот скритп для изменения второй БД.
Может есть и другие идеи...
Бред-с, извините. Во-первых, для этого Current_Timestamp или Now должны возвращать время коммита, а не выполнения операции, чего оне, безусловно, не делают, ибо делать не могут. Такой подход прокатит исключительно в случае выполнения указанной процедуры разогнавши всех усеров нафик, то есть в монопольном режиме, чтобы во время снятия реплики не было некоммиченных изменений.Андрей писал(а):
Вообще-то все делается гораздо проще:
1) Каждая таблица должна иметь поля DateCreate,DateModify, которые модифицируются в тригерах Insert, Update
2) Пишешь процедурку, которая создает следующий SQL-script
а) вставляет все записи, которые появились после DateTime
б) обновляет все записи, которые изменились после DateTime
И этот скрипт передаешь по мылу, а на месте всасываешь в БД
Вот именно. И удалять из лога данные о снятых изменениях или метить их "читано" при снятии.Андрей писал(а): для этого нужно вести полное протоколирование действий пользователей
Ну, подводными камнями чревато вообще всё, жить в принципе опасно и вредно. А вот организовать ведение лога силами IBExpert вполне разумно.Андрей писал(а): Использование для репликации IBExpert чревато подводными камнями.
Во-первых, для его задачи не требуется знать обо всех изменениях БД, требуется только фиксировать состояние БД на конкретный момент времени - раз в сутки или трое (выходные) а этот подход отлично решает эту задачу.Merlin писал(а): Бред-с, извините. Во-первых, для этого Current_Timestamp или Now должны возвращать время коммита, а не выполнения операции, чего оне, безусловно, не делают, ибо делать не могут. Такой подход прокатит исключительно в случае выполнения указанной процедуры разогнавши всех усеров нафик, то есть в монопольном режиме, чтобы во время снятия реплики не было некоммиченных изменений.
Если ты любитель IBExpert, то так и скажи.Merlin писал(а): Ну, подводными камнями чревато вообще всё, жить в принципе опасно и вредно. А вот организовать ведение лога силами IBExpert вполне разумно.
Любопытно. Раз в сутки плавно превратился в трое, а потом даже в неделю (выходные). Брюки превращаются... (С). Ещё раз: этот подход является велосипедом с многоугольными колёсами - в принципе может и поехать, но интенсивность ударов по многострадальной сильно зависит от количества углов. При модификации метаданных требует модификации алгоритмов съёма-наката или включения в эти алгоритмы блока топологического анализа reference integrity, требует необходимости озаботиться гарантированным отстутствием активности юзеров в момент снятия реплики. Ещё такой провокационный вопросик - что будем накатывать вперёд, а что потом - лог делетов или данные из таблиц? Или всё-таки бум думать о последовательности, в которой выполнялись операторы? А последовательность тоже бум по таймштампу с дискретом в секунду ловить или где? Тут пространство для раздумий веееесьма обширноеAnonymous писал(а): Во-первых, для его задачи не требуется знать обо всех изменениях БД, требуется только фиксировать состояние БД на конкретный момент времени - раз в сутки или трое (выходные) а этот подход отлично решает эту задачу.
Первое в общем случае неверно, второе расскажи например ребятам с биллинговыми системами, обхохочутсяAnonymous писал(а): Во-вторых, протоколирование нужно не полное, а только для удаленных записей, а это очень маленький объем - проверено.
Не угадал. Я любитель WISQL и isql.Anonymous писал(а): Если ты любитель IBExpert, то так и скажи.
Не буду смотреть, лень. В таком случае это скрипт не репликации, а пампа данных в монопольном режиме. А вот полуавтоматом IBExpert для ведения лога для репликации (идея стянута с ранних версий IBLogManager во времена их дружбы) - массированное создание триггеров по заданному шаблону - совершенно не грешно воспользоваться. Правда такая приблуда для себя любимого пишется за пару часов, но если есть, то почему не воспользоваться. Кстати, логом можно пользоваться и в режиме снятия текущего состояния: хранить в нём таблица - id - оператор, а данные тянуть с основных таблиц. Это колесо уже некруглое, требует дополнительной возни и возможны парадоксы, но во многих случаях ещё приемлемое.Anonymous писал(а): НАпример, посмотри скрипт репликации, который он выдает - он отключает все ограничения и тригера, вставляет данные, а потом включает. А это нарушение ссылочной целостности.