Для соединения, которое может рваться, можно использовать только Merge репликацию. Однако, и ее использование всех проблем не усраняет. Следует иметь в виду, что сам процесс синхронизации может быть продолжительным по времени и может быть прерван очередным обрывом связи. При этом синхронизация производится НЕ в рамках транзакции. А из этого следует, что в целевой БД могут возникнуть (стать видимыми в клиентских приложениях) не все реплицируемые записи, а их часть. Это может привести, например, к тому, что реплицируемая только что оформленная накладная, содержащая 10 строк, может на целевом сервере проявиться (и в таком виде выглядеть довольно продолжительное время!) как накладная всего из 2 строк. В конце концов, когда репликация наконец пройдет до конца, она превратиться в накладную из 10 строк. Но пользователь, увидевший ее как накладную из 2 строк ничего не значет о том, что она неполная и может принять неверное решение в процессе своей работы.

С огромным уважением отношусь к Александру Гладченко. Однако, в данном вопросе не могу с ним согласиться. Описанная мной проблема при использовании штатных средств Merge-репликации действительно имеет место по крайней мере, на версии 7.0 (проверено экспериментально, на версии 2000 пока не успел, возможно, что поведение иное). Я не утверждаю, что проблемы репликации неразрешимы, но решение этих проблем требут привлечения кроме штатных средств еще и средств собственной разработки, направленных на решение конкретных проблем. Решение, аналогичное предложению Виктора Светлова, планирую использовать и я. Только не с помощью вспомогательной базы данных, а с помощью импорта/экспорта в файл данных, изменившихся за определенный период. Для того, чтобы это стало возможным, в своей системе буквально все операции полностью журнализируются с помощью самопальных механизмов. А использовать можно все, что угодно - FTP, мыло, дискеты и т.д. В самопальных же механизмах описывается последовательность передачи данных в файлы и закачки данных из них. Предложенная Владимиром2 схема - один из вариантов самопального решения проблем репликации. Эта схема направлена на решение конкретных проблем. Да, действительно, можно в таблице, где хранится заголовочная информация накладной добавить дополнительное поле, в котором сохранять количество строк накладной (а еще более надежно - контрольную сумму всех полей). Накладная, у которой реальное количество строк (контрольная сумма) отличается от указанного в заголовке, должна считаться не полностью перекачанной. Та проблема, решение которой Владимир2 привел во второй части своего постинга, решается совершенно по-разному (или не решается вовсе) на разных предприятиях. На одних предприятиях вероятность возникновения подобной ситуации пренебрежимо мала, а отдельные нестыковки решаются индивидуально в случае их возникновения организационно. В других (среднее решение) - методами, аналогично предложенному. В третьих даже секундное рассогласование между данными считается совершенно недопустимым, тогда используются механизмы распределенных транзакций (которые на рвущейся медленной линии, конечно же неприемлемы и которые приводят к существенному снижению надежности всей системы вцелом).
Кроме высвеченных проблем существует еще огромное море проблем, полное решение которых мне не удалось пока увидеть ни у кого. Обычно достигается некоторый компромис между трудоемкостью разрешения проблем организационными мерами и с помощью репликационных механизмов совместно с собственными техническими решениями. Одна из наиболее часто встречаемых проблем - проблема Foreign key. Если одна таблица ссылается на некие справочные данные другой таблицы, и между ними установлено ограничение целостности Foreign key, то возникают жесткие требования к тому, в какой последовательности должна передаваться информация об изменении содержимого этой пары таблиц. Удаление - сначала на стороне "многие", потом на стороне "один". Добавление наоборот - сначала на стороне "один", потом на стороне "многие". Когда таких связей целая паутина, запутаться немудрено. Одно из самых простых проблем - установить опцию Not for replication для соответствующих ограничений целостности (а также для триггеров, которые выполняют аналогичные функции). Однако, при этом в таблицах могут временно возникать "потерянные" записи (не имеющие ответной части на стороне "один"), и бизнес-логика, заложенная в алгоритмах хранимых процедур, хапросов, посылаемых с клиента и т.д. и ориентированная на заведомо гарантированную логическую целостность данных может выдать некорректные результаты.
Мой постинг уже величиной со статью, а, вроде бы ничего существенного и не сказал ...