Рыжий КотПредположим такой случай: по какой-то причине было сформировано 2 одинаковых сообщения (например при посылке на фтп оборвалась связь, файл остался, но отсылатель решил перепослать еще раз). Т.е. транспортный уровень дал сбой. Откатят ли СУБД такую ошибку в ваших случаях? Используете ли вы дополнительные средства проверки (CRC, например) для отсылаемых/принимаемых сообщений
Ну у нас фтп не используется - только прямое текущее соединение.
Но если про контроль - при добавлении одинакового события в таблицу оно прсто не добавится. При обработке, если ошибка - откат естественно, потому как под транзакцией исполняется. Проверять нечего в принципе.

vadiminfoРепликация черех ХП выглядит не так убедительно как родная, которая берет на себя все ф-ии по надежности, сравнению отличий на сайтах и вообще поодержке актуальности копий. Дает полную картину того что произошло не так. По крайней мере, в Оракле так и обчтоит. ХП - допустима, но она уступает в конечном счете. У нас были обе в эксплуатации. От ХП отказывемся.
Это смотря как у вас было сделано. Расскажите, про репликацию на ХП, от которой отказываетесь.
Для нас наша репликация кажется наоборот более убедительной. Почему? Потому что
1. Полный контроль. Все зависит не от "настроения" репликации сервера, а от меня - чего захотел, того получил. Без недо или пере .
2. Возможность при репликации выполнять другие, достаточно необходимые действия. Потому как если говорить просто про идентичность данных в таблицах, то это самое простое. Однако у нас есть гораздо сложнее задача: при переливе данных проделать еще некоторые важные и нужные действия над этими данными и над другими. А это простой репликацией не получится. Можно использовать конечно и триггеры - но какая разница? К тому же триггер должен понимать, кто изменил данные - репликация или клиент. Да еще и при необходимости реплицировать только конкретные поля, все-равно придется это описывать, а в ХП это по умолчанию используется - какие параметры входящие, то и пишется. Ну а сложность написания ХП для каждого события - если бы все было таким сложным :))

-- Tygra's --

Александр ГoлдунТогда это не имеет ничего общего с off-line репликацией:
А никто и не говорил про off-line репликацию.
Разговор идет о репликации вообще. Зачем нам офф, если у нас есть каналы и так. Когда понадобится, тогда сделаем. Это тоже не тяжело будет, даже основываясь на том же механизме - ХП. Только лишнее звено появится - передача результата обратно. И все.

Александр ГoлдунВ ASA под понятием любой канал, а точнее транспорт, подразумевается
SMTP, FTP, file-sharing, MAPI, Lotus VIM и даже курьер с дискеткой либо самосвал
с CD-RW. И все это прозрачно для разработчика
А нас не ASA, и (независимо от этого) у нас под каналом понимается канал, а не способ передачи. Согласитесь, что способ передачи данных звучит корректнее, чем канал . И в заблуждение никого не введет.
К тому же повторюсь - захотели разработчики ASA написать такую репликацию, значит молодцы. Но мне от этого не легче. Точнее, мне от этого все-равно. У меня MS SQL, on-line каналы, заточенный под это механизм репликации, который покрывает не только область самой передачи данных, но и еще область их обработки, и мне живется хорошо и универсально :)). Когда придет время реплицировать оффлайном, тогда и займусь этим (надеюсь что не придет, т.к. сейчас онлайн можно поднять куда угодно, да и специфика работы не та).

ЗЫ
Кстати, наш механизм репликации в силу его ХП-шности позволяет даже ничего не реплицируя выполнять нужные действия на принимающей стороне по событию репликации.

-- Tygra's --

Александр ГoлдунА что в этом удивительного при on-line связи и при чем здесь репликация? Подключаешься к базе и делаешь с ней что угодно.
В ASA это элементарно делается даже в off-line режиме
Вы руками чтоли будете делать? Мониторить вручную пару миллионов объектов?
И почему при слове "репликация" у вас ассоциация только с передачей данных из одного места в другое? Данные можно менять не только путем передачи из другого места этих же измененных данных, но и по событию их изменения какими-то действиями на принимающей стороне. Никак по-другому эти действия не обозвать.

ASCRUSЭто тоже в ASA автоматом. И в триггерах можно понять, кто их вызывает - сессия или репликация. И даже специальные триггера есть на репликацию, в теле которых можно выявить конфликтующие поля и решить что делать дальше.
Ну это хорошо. ASA рулит.
В принципе получается почти одинаковый механизм, если не брать в рассчет online соединение.

-- Tygra's --

Александр Гoлдун tygra Александр ГoлдунА что в этом удивительного при on-line
связи и при чем здесь репликация? Подключаешься к базе и делаешь с ней
что угодно.
В ASA это элементарно делается даже в off-line режиме
Вы руками чтоли будете делать? Мониторить вручную пару миллионов объектов?


Не понял вопроса. Можно не вручную. Можно навесить обработчики разных
событий по репликации, типа начало, конец и т.п. Можно просто послать
удаленной базе на исполнение любой вопрос.
Уточните, плиз, в чем прикол и что значит "мониторить пару миллионов
объектов", а так же связь этого с репликацией
Уточняю: я выделил красным болдом то, чего не понял и к чему мой комментарий. Если при изменении данных вам нужно чего-то сделать в БД-приемщике, вы же не будете это делать руками? Ну, уже пояснили, что приделаете обработчики разных событий по репликации . Вот я о том же и говорил. Только вы будете отдельно их навешивать, а у нас все вместе и сразу. Только этим и отличается

Александр Гoлдун tygra
И почему при слове "репликация" у вас ассоциация только с передачей данных из одного места в другое?


А с чем должна быть ассоциация еще?

replication сущ.
....
3) а) копирование; дублирование; повторение
б) тиражирование, размножение

(c) Lingvo 6, словарь Lingvo Universal
.........
Это все понятно, но программируем то мы и системы строим не по переводу понятий, а по их применению.

Александр Гoлдун tygra
Данные можно менять не только путем передачи из другого места этих же измененных данных, но и по событию их изменения какими-то действиями на принимающей стороне. Никак по-другому эти действия не обозвать.

Элементарный триггер на таблице на принимающей стороне.
С триггерами будет работать тяжелее. Нужно понять, кто менял данные, да и обновлять нужно в двух местах - репликация и триггер.

Но вообще кому как нравится. И у кого что есть. У ASA есть встроенная репликация - хорошо. У MS SQL нет, а та, что есть, не очень то, поэтому гораздо проще, удобнее и универсальнее использовать свою (тем более, что она много чего позволяет).

-- Tygra's --

Тема давно поменялась уже :)

-- Tygra's --