|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
12.09.2002, 19:55:11
|
|||
|---|---|---|---|
|
|||
Merge replication и изменения данных |
|||
|
#18+
Упрощенное описание проблемы: Чтобы проверить в триггере, изменялась ли колонка, достаточно запросить if update (col_name). На основе этой информации формируем запись в некий лог в своем формате. Все чудесно. Теперь тоже, но с репликацией - когда на одном сервере меняем запись ( только одно поле ), то на нем в лог аккуратно падает изменение в одном поле. Когда изменения доползают до других серверов и на них срабатывают такие же триггера, то они выдают, что пришли изменения на все поля . Merge replication. 1) Почему так? 2) Как с этим бороться? :-)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.09.2002, 10:15:25
|
|||
|---|---|---|---|
Merge replication и изменения данных |
|||
|
#18+
1.Потому что SQL не хранит информацию о о том, КАКИЕ ПОЛЯ изменены.Он хранит информацию КАКИЕ ЗАПИСИ изменены. 2.Бороться наверное так: В триггера добваить что-то вроде if sessionproperty('replication_agent') <> 1 Begin Текст триггера End Таким образом на мерж-агент триггера реагировать не будут, а таблицу с логом реплицировать отдельно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.09.2002, 10:23:47
|
|||
|---|---|---|---|
|
|||
Merge replication и изменения данных |
|||
|
#18+
Не пойдет - мне нужно отслеживать изменения в любом случае. Флажок этот я и так выставляю в своем логе :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.09.2002, 10:36:57
|
|||
|---|---|---|---|
Merge replication и изменения данных |
|||
|
#18+
А когда синхронизируется апдэйт таблицы, имеющей поле Timestamp, у тебя добавляется в лог одна запись или две? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.09.2002, 11:47:15
|
|||
|---|---|---|---|
|
|||
Merge replication и изменения данных |
|||
|
#18+
С timestamp'ом тоже самое - в триггере if update(...) выдает true для всех полей. Кроме самого timestamp'а. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.09.2002, 12:23:35
|
|||
|---|---|---|---|
Merge replication и изменения данных |
|||
|
#18+
У меня если апдэйтится табличка с timestamp,после синхронизации в табличку с логом кидается 2 записи, причем, одна-со старыми значениями всех полей,вторая-с новыми.Такое впечатление, что мерж-агент сначала отдельно апдэйтит timestamp, а потом, вторым апдэйтом-все остальное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.09.2002, 12:53:21
|
|||
|---|---|---|---|
|
|||
Merge replication и изменения данных |
|||
|
#18+
Все остальное - это все поля, кроме timestamp'а? Или же только те, что реально участвовали в update'е? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.09.2002, 14:59:55
|
|||
|---|---|---|---|
Merge replication и изменения данных |
|||
|
#18+
Я не утверждаю, что апдэйт проходит на все поля, т.к. не проверял. У меня триггер реагирует на деятельность мерж-агента, и тупо кидает в другую таблицу содержимое инсертед и делетед. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.09.2002, 15:15:04
|
|||
|---|---|---|---|
|
|||
Merge replication и изменения данных |
|||
|
#18+
Блин! Посмотрите на мое первое сообщение, плз :-) Меня интересует именно то, что обновления на репл. партнерах приходят для всех полей , а не для одного , как на том сервере, где происходили изменения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.09.2002, 16:23:35
|
|||
|---|---|---|---|
Merge replication и изменения данных |
|||
|
#18+
Посмотри на МОЕ первое сообщение, плз . Исходя из того, КАК и ЧТО хранится в MSMERGE_CONTENTS я предполагаю(а точнее утверждаю с 90% уверенностью), что мерж-агент действительно апдэйтит ВСЕ поля. А последующий мой вопрос был просто дальнейшим развитием беседы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.09.2002, 16:33:22
|
|||
|---|---|---|---|
|
|||
Merge replication и изменения данных |
|||
|
#18+
Ясно. Меня интересовало именно то, какие поля меняются. Сам факт и то, какие записи менялись, отловить проблем не составляет. В любом случае спасибо за участие! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
13.09.2002, 18:59:08
|
|||
|---|---|---|---|
Merge replication и изменения данных |
|||
|
#18+
Если сильно приспичило, поковыряйся в процедурах типа sp_upd_A23733705B954A4127B390A57F794816. Для апдэйта мерж агенит вызывает их. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.09.2002, 07:55:07
|
|||
|---|---|---|---|
Merge replication и изменения данных |
|||
|
#18+
Если я ничего не путаю, то при настройке репликации есть галочка, которая указывает как считать изменения по столбцам или по строкам. BOL под рукой нет и сервера тоже, так что вполне возможно, что несу чушь и указанные свойства можно проставить только для резолвера. З.Ы. Кстати, обратил внимание, что в 2000-м значительно гибче можно настраивать репликацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
14.09.2002, 20:11:13
|
|||
|---|---|---|---|
|
|||
Merge replication и изменения данных |
|||
|
#18+
Да, эта галочка соот-т п-ру @column_tracking в sp_addmergearticle. По умолч. он установлен в false, что означает ситуацию конфликта даже если в одной записи апдейтились разные поля. Возникает гипотеза, что механизм отсл-я конфликтов всегда работает на уровне отд.полей, и конфликт уровня записи достигается выставлением флажков обновления во всех ее полях, что Вы и пронаблюдали. Не факт, что гипотеза верна, но проверить оч.просто - поставить @column_tracking = true. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=46&tablet=1&tid=1820333]: |
0ms |
get settings: |
4ms |
get forum list: |
10ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
44ms |
get topic data: |
6ms |
get forum data: |
2ms |
get page messages: |
28ms |
get tp. blocked users: |
1ms |
| others: | 197ms |
| total: | 296ms |
| 0 / 0 |
