Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Репликация. Update.
|
|||
|---|---|---|---|
|
#18+
есть такая ситуация. 1 репликация транзакционная 2 публикации одинаковы на двух серверах 3 идет она туда-сюда, почти по кругу (стоит фильтр). 4 делаем инсетрт на одном сервере, он реплицируется на другой 5 на другом к этой записи делаем апдейт, И ТУТ при репликации обратно, пишется Violation of PRIMARY KEY constraint 'PK_s666'. Cannot insert duplicate key in object 's666'. Что за фигня? Ведь был апдейт. Видимо где-то что-то я не читал, но ГДЕ и ЧТО??? == Памажите. Плиз. Все уже на издохе из-за этой репликации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.05.2001, 16:37 |
|
||
|
Репликация. Update.
|
|||
|---|---|---|---|
|
#18+
Не нужно было такое название констрейнту давать ))... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2001, 14:26 |
|
||
|
Репликация. Update.
|
|||
|---|---|---|---|
|
#18+
ха-ха! Шея уже в петле, ща тока вы мне табурет сдвините, и я кони двину от этой репликации. == Имя констр вымышленное. == мож тада кто кинется ссылкой какой, где репликация расписана не типа перевод хелпа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.05.2001, 15:53 |
|
||
|
Репликация. Update.
|
|||
|---|---|---|---|
|
#18+
Репликацией транзакций практически не занимался (практически-в основном merge-), читал теоретически в "Руководство АБД MS SQLServer 7.0" Марк Шпеник & Оррин Следж по кот. и сам учусь.Но пришла мысль:может быть при настройке репл. не был установлен переключатель у пункта 'Yes,allow immediate-updating subscriptions, т.к. в этом случае создаются столбцы с временными метками для таблиц подлежащих репл. по кот. и решаются конфликты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2001, 07:37 |
|
||
|
Репликация. Update.
|
|||
|---|---|---|---|
|
#18+
Дело не в конфликтах, а в неясности почему UPDATE на одной стороне заменяется INSERT на другой. (немедленнки не подходят для нашей системы) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2001, 09:29 |
|
||
|
Репликация. Update.
|
|||
|---|---|---|---|
|
#18+
С месячишко назад это открытие уже звучало на форуме (искать не охота). Да, Update заменяется на Delete и Insert. Смирись. Переделай свойства DRI, триггеров с учетом сказанного. А вот почему у тебя добавление срабатывает раньше удаления - вот это действительно интересно (судя по всему, отсюда и ноги выросли). Направь свою мозговую энергию на решение этого вопроса, остальные преодолимы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.05.2001, 16:21 |
|
||
|
Репликация. Update.
|
|||
|---|---|---|---|
|
#18+
Все прально. Delete Insert - это известно Тока вот и вся беда в в инсерте А задача такая есть два сервера реплицируем транзакционно таблицу. у неё есть поле для фильтра реплики, допустим "zzz" При инсерте на первом сервере, zzz присваивается 1, с этим значением запись отправляеся на второй сервер. На втором делаем апдейт записи плюс zzz=2 и отправляем на первый сервер, соответственно при апдейте на первом zzz присваивается 1 условие фильтра репликации для первого сервера все кроме zzz=2 условие фильтра репликации для второго сервера все кроме zzz=1 и вот када реплицируем апдейт возникает "не могу вставить дубликат....", будто небыло никакого делете. а мож какм-то образом просыпается первый инсерт и возвращается обратно????? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2001, 14:33 |
|
||
|
Репликация. Update.
|
|||
|---|---|---|---|
|
#18+
Извините, вклинюсь с вопросом почти по теме. Есть 2 таблицы T1 и T2, связанные внешним ключом. Я изменяю одно из полей родителя. При транзакционной репликации вместо update пойдет delete/insert. Только как же это может нормально сработать, если на родителя есть ссылки ? Delete ведь не пройдет в этом случае! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2001, 15:24 |
|
||
|
Репликация. Update.
|
|||
|---|---|---|---|
|
#18+
А не подскажите, замена Update на Delete и Insert описывается где-то? Можно это использовать, или поведение репликации может измениться? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.05.2001, 16:03 |
|
||
|
Репликация. Update.
|
|||
|---|---|---|---|
|
#18+
2All. Ребята, я же про все это только в книжках читал. Кстати, у Мамаева описано довольно подробно. Руками щупал только MERGE и SNAPSHOT. И то, только в порядке эксперимента. А брякнул только то, о чем слышал на этом же форуме. 2moonspell13. SQL2000? Я пока не изучил этот вопрос подробно, но только в SQL2000 можно настроить репликацию транзакций так, что и подписчик сможет возвращать издателю внесенные им модификации записей (написано у Мамаева). Как это сделать, пока не знаю (еще не дочитал). Возможно, ты случайно именно так ее и настроил? И еще вопрос - почему именно репликация транзакций? Почему не Merge? У тебя что, хорошие скоростные соединения? Для такого случая можно и непосредственно обновляемых подписчиков использовать. 2GreenSunrise. Вот как раз на эти грабли и наткнулся задавший вопрос на форуме в прошлый раз. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.06.2001, 14:15 |
|
||
|
Репликация. Update.
|
|||
|---|---|---|---|
|
#18+
Всем здра. Работаем под скл7 сп1 В скл2000 расширена репл. транз., согласен, но ёго ставить на данный момент нет возможности, а у некоторых и желания. Мерж по некоторым причинам (довольно веским) не подходит. Да и есть каналы которые в ближайшее время тока модемные будут. А вот очень интересно узнать про возврат изменений, похоже что от этого все беды. Кто-нибудь знает подробнее про эти настройки. Но похоже что это только для 2000 сервера. Если и в 7 такое плизЪ, подскажите, где? что? Всем досв. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.06.2001, 10:33 |
|
||
|
|
start [/forum/topic.php?fid=46&msg=32006930&tid=1826592]: |
0ms |
get settings: |
6ms |
get forum list: |
9ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
26ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
32ms |
get tp. blocked users: |
1ms |
| others: | 211ms |
| total: | 298ms |
| 0 / 0 |
