|
|
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
Hello, All! Есть 2 идентичные таблицы в консолидированной и удаленной базе. Реплицируются полностью. Вставка записей деается в обеих базах. В консолидированной базе на триггере before insert заполняется одно из полей. В удаленной базе значение этого поля узнать заранее невозможно, но оно там необходимо, пусть даже с задержкой на время обмена изменениями. dbremote запускается с параметром "-t". Если вставка делается в консолидированной базе, то триггер отрабатывает, вставляет значение и это значение прекрасно передается в удаленную базу. Если же вставлять в удаленной, то происходит следующее: поле получает значение NULL (в удаленной нет триггера), потом вставка реплицируется в консолидированную и уже там триггер заполняет значение поля. Но это заполнение обратно в удаленную таблицу не возвращается! В результате появляется расхождение в данных. Как получить обратно в удаленной базе значение, вставленное триггером в консолидированной? -- With best regards, Alexander Goldun http://talk.ru/forum/talk.ru.accounting.development ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2004, 19:30 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
Убрать ключ -t? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2004, 19:39 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
White OwlУбрать ключ -t? :) Тогда не будет реплицироваться значение даже при вставке в консолидированной базе ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.08.2004, 19:41 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
Шальная мысль появилась: а что, если поля, которые триггер апдейтит, каким-то образом еще раз апдейтить сами на себя? Чтобы изменения в лог репликации попали. Ну, там, через event али еще как ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2004, 00:52 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
Иметь одинаковую логику (триггера) в удаленной и конс. базе. Реплицировать с триггерами, но dbremote запускать от имени юзера с отключеннными триггерами. Если так не подходит, то, как предложил, mustlive, городить какой-нибудь огород с ивентами или помежуточными таблицами с доп. триггерами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2004, 13:21 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
mustliveШальная мысль появилась: а что, если поля, которые триггер апдейтит, каким-то образом еще раз апдейтить сами на себя? Чтобы изменения в лог репликации попали. Ну, там, через event али еще как Приходила в голову такая идея. Можно было бы убрать в консолидированной базе триггер и по расписанию, например раз в минуту, задавать значение полю для записей, в которых оно NULL. Проверял, работает. Но, во-первых, это выглядит, как через ж.., во вторых потребует некоторой переделки логики в консолидированной базе. Сейчас в консолидированной это поле должно быть NOT NULL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2004, 15:53 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
Aleksey Kh.Иметь одинаковую логику (триггера) в удаленной и конс. базе. Невозможно в данном случае В общем понятно. Красивого решения никто не знает. Придется перекраивать логику ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2004, 15:58 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
автор Приходила в голову такая идея. Можно было бы убрать в консолидированной базе триггер и по расписанию, например раз в минуту, задавать значение полю для записей, в которых оно NULL. Проверял, работает. Но, во-первых, это выглядит, как через ж.., во вторых потребует некоторой переделки логики в консолидированной базе. Сейчас в консолидированной это поле должно быть NOT NULL. Я имел ввиду несколько другое, относящееся к ЭТОЙ ситуации: автор Если же вставлять в удаленной, то происходит следующее: поле получает значение NULL (в удаленной нет триггера), потом вставка реплицируется в консолидированную и уже там триггер заполняет значение поля. Но это заполнение обратно в удаленную таблицу не возвращается Для того, чтобы "заполнение вернулось обратно", нужно сделать UPDATE тех полей, которые обработал триггер на консолидированной, сами на себя. Единственная загвоздка - как определить, какие поля были обработаны триггером при последнем обмене, другими словами, какие данные пришли из удаленной базы. Еще вариант: интересно, можно ли из триггера вызвать процедуру, которая будет проводить update? Если да, то данные вернутся в удаленную базу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2004, 17:12 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
К моему предыдущему посту: может, чем помогут процедуры типа sp_hook_dbremote_receive_end ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2004, 17:36 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
mustlive Для того, чтобы "заполнение вернулось обратно", нужно сделать UPDATE тех полей, которые обработал триггер на консолидированной, сами на себя. Единственная загвоздка - как определить, какие поля были обработаны триггером при последнем обмене, другими словами, какие данные пришли из удаленной базы. А ты уверен, что неизменяющий апдейт вида UPDATE table1 SET field1=field1 будет реплицироваться? Я очень сомневаюсь. Он даже в transaction log не попадет скорее всего mustlive Еще вариант: интересно, можно ли из триггера вызвать процедуру, которая будет проводить update? Если да, то данные вернутся в удаленную базу. Вызвать то можно, но разницы никакой, что прямой апдейт из триггера, что процедура ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2004, 18:09 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
mustliveК моему предыдущему посту: может, чем помогут процедуры типа sp_hook_dbremote_receive_end ? Это уже предложили на англоязычном форуме. Принципиальной разницы мехду хуками и ивентами тут нет. В общем придется передлывать логику либо наворачивать более громоздкую репликацию, навешивать связанные таблицы и т.п. Я просто хотел получить более элегантное решение ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2004, 18:12 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
автор А ты уверен, что неизменяющий апдейт вида UPDATE table1 SET field1=field1 будет реплицироваться? Я очень сомневаюсь. Он даже в transaction log не попадет скорее всего Почему же? Серверу должно быть все равно, на то же значение апдейт или на другое. Он просто фиксирует факт апдейта в логе автор Это уже предложили на англоязычном форуме. Принципиальной разницы мехду хуками и ивентами тут нет. Если повесить апдейт в эту процедуру, то должно получиться так: получены данные из удаленной базы, вызывается эта процедура и в ней значения нужных полей апдейтятся. В рез-те UPDATE'ы должны попасть в лог и уйти в удаленную базу. Вроде бы, задача решена. Это гораздо лучше, чем ежеминутно проверять в event'е значения на NULL, как ты пробовал ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.08.2004, 20:49 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
Серверу должно быть все равно, на то же значение апдейт или на другое. Он просто фиксирует факт апдейта в логе. Я точно не знаю, попадает-ли это в лог, но если значение поля не изменилось, по обмену такая транзакция не уедет точно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2004, 12:15 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
автор Я точно не знаю, попадает-ли это в лог, но если значение поля не изменилось, по обмену такая транзакция не уедет точно. Я точно не знаю, сам не пробовал, что происходит, если значение поля не изменилось. Но это решаемо: делаем 2 UPDATE: на 0 (zero) и на нужное значение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2004, 13:24 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
mustlive автор А ты уверен, что неизменяющий апдейт вида UPDATE table1 SET field1=field1 будет реплицироваться? Я очень сомневаюсь. Он даже в transaction log не попадет скорее всего Почему же? Серверу должно быть все равно, на то же значение апдейт или на другое. Он просто фиксирует факт апдейта в логе Вот именно, что там фиксируются факты апдейтов, а не факты выполнения оператров. mustlive автор Это уже предложили на англоязычном форуме. Принципиальной разницы мехду хуками и ивентами тут нет. Если повесить апдейт в эту процедуру, то должно получиться так: получены данные из удаленной базы, вызывается эта процедура и в ней значения нужных полей апдейтятся. В рез-те UPDATE'ы должны попасть в лог и уйти в удаленную базу. Вроде бы, задача решена. Это гораздо лучше, чем ежеминутно проверять в event'е значения на NULL, как ты пробовал Может и лучше, но не решает проблемы в корне. У меня сейчас в консолидированной базе то поле NOT NULL и по логике не может быть NULL. Придется либо это менять, либо навешивать в репликацию еще несколько таблиц, чтоб можно было сгенерить это поле в удаленной базе. В общем, проехали. Как решить задачу хоть как нибудь я знаю с самого начала. Просто придется обойтись без красивых решений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2004, 18:00 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун mustlive автор А ты уверен, что неизменяющий апдейт вида UPDATE table1 SET field1=field1 будет реплицироваться? Я очень сомневаюсь. Он даже в transaction log не попадет скорее всего Почему же? Серверу должно быть все равно, на то же значение апдейт или на другое. Он просто фиксирует факт апдейта в логе Вот именно, что там фиксируются факты апдейтов, а не факты выполнения оператров. mustlive автор Это уже предложили на англоязычном форуме. Принципиальной разницы мехду хуками и ивентами тут нет. Если повесить апдейт в эту процедуру, то должно получиться так: получены данные из удаленной базы, вызывается эта процедура и в ней значения нужных полей апдейтятся. В рез-те UPDATE'ы должны попасть в лог и уйти в удаленную базу. Вроде бы, задача решена. Это гораздо лучше, чем ежеминутно проверять в event'е значения на NULL, как ты пробовал Может и лучше, но не решает проблемы в корне. У меня сейчас в консолидированной базе то поле NOT NULL и по логике не может быть NULL. Придется либо это менять, либо навешивать в репликацию еще несколько таблиц, чтоб можно было сгенерить это поле в удаленной базе. В общем, проехали. Как решить задачу хоть как нибудь я знаю с самого начала. Просто придется обойтись без красивых решений. А может просто посмотреть на логику и повесить триггер не на before, а на after, и если поле NULL, то как раз его и апрейдить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.08.2004, 12:50 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
Sergey Orlov А может просто посмотреть на логику и повесить триггер не на before, а на after, и если поле NULL, то как раз его и апрейдить... Как много абстрактных советов. Такое ощущение, что никто с этим реально не сталкивался. Действия триггера after в консолидированной базе над записями, пришедшими из удаленной, так же не реплицируются обратно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.09.2004, 16:48 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
Можно извратится следующим образом: допустим реплицируется таблица t1 делаем идентичную t2 на тригере в t1 вставляем аналогичные записи и в t2 потом в хук процедуре после применения (типа sp_hook_dbremote_receive_end) делаем: delete from t1 where ...есть такое в t2; insert into t1 select from t2; delete from t2; ....и все будет пучком ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.09.2004, 11:11 |
|
||
|
ASA 9.0.1 Репликация триггеров
|
|||
|---|---|---|---|
|
#18+
Александр Гoлдун Sergey Orlov А может просто посмотреть на логику и повесить триггер не на before, а на after, и если поле NULL, то как раз его и апрейдить... Как много абстрактных советов. Такое ощущение, что никто с этим реально не сталкивался. Действия триггера after в консолидированной базе над записями, пришедшими из удаленной, так же не реплицируются обратно. С учетом того, что используется dbremote, который обрабатывает transaction log, действительно получается такая ситуация, в одном проекте еще в 5.5, я подобную ситуацию решал добавлением поля, в которое триггером в каждой базе автоматически всталялась имя базы, если значение по умолчанию было NULL, после вставки из удаленных запускалась процедура. которая в принципе повторяла действия триггера на другие поля на записи из других баз. В твоем случае может поступить след. образом: разрешить вставку NULL, триггер срабатывает если не NULL, а изменение данных делать после осуществления репликации процедурой на соответствия NULL, чтобы они точно попали в transaction log. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.09.2004, 13:32 |
|
||
|
|

start [/forum/topic.php?fid=55&msg=32669976&tid=2014246]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
38ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 12ms |
| total: | 149ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...