Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Еще раз о merge репликации и GUID
|
|||
|---|---|---|---|
|
#18+
Вопрос, наверно, дурацкий: В merge репликации учавствует несколько таблиц справочного характера с ключевыми полями типа IDENTITY, которые никогда не будут изменяться на подписчике. Но при создании публикации с помощью Create Publication Wizard, в эти таблицы упорно добавляются поля GUID (при запуске snapshot agent). Нельзя ли как-то этого избежать? И вообще, можно ли в merge репликации как-то обозначить, что эта конкретная таблица не обновляется на подписчике (пока у меня просто клиентский софт не предоставляет такой возможности). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2001, 13:45 |
|
||
|
Еще раз о merge репликации и GUID
|
|||
|---|---|---|---|
|
#18+
Не добавлять GUID'ы нельзя, потому что они используются при merge репликации для идентификации записей. Проще, если у вас первичный ключ уже типа uniqueidentifier, тогда можно сиквелу указать, что он может использовать эту колонку, а не создавать свою. Но это, конечно, не всегда возможно. Указать, что данная таблица не обновляется на подписчике, насколько я знаю, нельзя. Только использовать обходные пути, которые собственно к репликации уже не имеют отношения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2001, 14:24 |
|
||
|
Еще раз о merge репликации и GUID
|
|||
|---|---|---|---|
|
#18+
Спасибо за ответ. Все-таки лыжи не едут, а не я не в порядке. Придется смириться, и есть, что дают. "Что не положено, то и не съедено. А коли не съедено, значит на то причины есть. Ну и зачем же я буду есть причины?!" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2001, 15:55 |
|
||
|
Еще раз о merge репликации и GUID
|
|||
|---|---|---|---|
|
#18+
Если таблицы на подписчике меняться не будут - нафиг тебе merge??? Merge задуман специально для обновления всеми кто пожелает и GUID для этого просто необходим. Другое дело, если у тебя SQL-server висит на Professional - тогда, понятно, transact недоступен, тут уж приходится выбирать - либо поставить W2000server, либо мириться с GUID. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2001, 18:25 |
|
||
|
Еще раз о merge репликации и GUID
|
|||
|---|---|---|---|
|
#18+
2 albatros. А самы-то вы пытались использовать репликацию транзакций на рвущихся модемных линиях? Не пытались? Повезло! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2001, 18:45 |
|
||
|
Еще раз о merge репликации и GUID
|
|||
|---|---|---|---|
|
#18+
Доброе утро, Garya! Не только пытался, но и настроил и работает! Кстати, transact работает лучше и легче настраивается! Может речь идет о подписчиках немедленного обновления??????????? Тренируйтесь... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2001, 18:56 |
|
||
|
Еще раз о merge репликации и GUID
|
|||
|---|---|---|---|
|
#18+
albatros < поделитесь опытом, тема уж больно злободневная. Многие хотят настроить репликацию транзакциями на плохих линиях, а вот не получается... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.12.2001, 19:46 |
|
||
|
Еще раз о merge репликации и GUID
|
|||
|---|---|---|---|
|
#18+
Связи не было, поэтому не могла ответить (кстати о модемных линиях) 2 albatros: Я, наверно, плохо объяснила - обновляться на подписчике не должны не все таблицы репликации - а только некоторые справочные, а большинство таблиц как раз очень даже обновляются. По поводу transact - связи пока нет вообще никакой, и неизвестно будет ли и когда, поэтому выбрана merge с Access. А как ее будут доставлять - может поездом возить - это не моя головная боль. На это начальник есть. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.12.2001, 11:10 |
|
||
|
Еще раз о merge репликации и GUID
|
|||
|---|---|---|---|
|
#18+
2 Albatros. Пожалуйста, проведите такой эксперимент. Создайте таблицу. Добавьте в нее 10000 записей. Настройте репликацию транзакциями по модему, произведите снапшот-синхронизацию. Проапдейте записи новыми значениями. Запустите синхронизацию репликацией транзакций. Загляните с помощью EM в блокировки - проверьте, какой тип блокировки на таблицу у вас выставил агент репликации. Выдержав небольшую паузу, оборвите связь во время синхронизации (выдернув штеккер из розетки). Снова загляните в блокировки. Запустите апдейт таблицы-источника новым значением. Воткните штеккер обратно и дождитесь хендшейка (если сможете). Во время второй синхронизации выдержав паузу снова разорвите связь и посмотрите опять значения целевой таблицы и выставленные блокировки. Ответтье пожалуйста на вопросы: 1. Какой тип блокировки выставил агент репликации при синхронизации первых изменений? Что будет с транзакциями, которые во время репликации попытаются обратиться к таблице во время синхронизации? 2. Что вы видите в целевой таблице после прерывания связи? 3. Нет осталась ли висеть блокировка, оставленная агентом репликации? 4. Запустилась ли вторая репликация транзакций и не прервалась ли она по причине выставленной на таблицу блокировки со времени первой синхронизации? 5. Если запустилась-таки, то что вы видите в таблице после второго прерывания связи? P.S. Полагаю, все эти эксперименты Вы уже сделали на полигоне при настройке репликации, и ответы на все вопросы вам заранее известны. Поэтому не сочтите пожалуйста мои вопросы как руководство к действию - они заданы в таком виде лишь для приближения к форме лабораторных испытаний. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.12.2001, 17:37 |
|
||
|
|

start [/forum/topic.php?fid=46&msg=32018703&tid=1824638]: |
0ms |
get settings: |
9ms |
get forum list: |
19ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
61ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
1ms |
| others: | 264ms |
| total: | 413ms |

| 0 / 0 |
