[gl00mie]

Цитата:

Сообщение от sergeypp

На текущий момент я вижу следующие проблемы при реализации репликации
RecID. Генерация «своих» RecID на подписчиках.
Номерные серии на подписчике
Добавление новых полей в таблицы сводится к пересозданию всей репликации
Код фирмы ‘dat’.

Мне кажется, эти и другие проблемы являются убедительными аргументами против непосредственного применения штатной MsSQL'ной репликации. По любому понадобится некая прослойка в самом приложении, которая будет заниматься репликацией и "сглаживанием острых углов". К слову, с RecId может быть связано множество нехороших побочных эффектов, например, это может проявиться в таблице адресов, текстов склада и прочих, использующих связи по RecId.

Цитата:

Сообщение от sergeypp

Возможен вариант, что бы аксапта сама отслеживала изменения, внутренним функционалом, а потом делала SQL инструкцию по вставке данных в другую базу в таблицу (Кстати так и работет репликация Коруса для Кристалла)

Ну вот и подтверждение обоснованности такого варианта

Цитата:

Сообщение от sergeypp

Как закатывать данные в аксапту? можно хранимкой, но тут возникает проблема сгенерацией RecID. Можно написать пакет в аксапте, который будет с определенной периодикой закатывать запросы к соседней базе в SQL инструкции, обрабатывать полученные данные и вставлять их внутренними средствами.

Если реализовать репликацию с использованием прослойки в приложении, то эта же прослойка может давать сигнал подписчикам, что есть данные для обновления и следует их загрузить. При этом можно не "заставлять" подписчиков загружать данные, а именно информировать, а уж подписчик при наличии такого сигнала отработает репликацию в подходящий момент. Именно так, во всяком случае, происходит репликация данных Active Directory между доменными контроллерами...