Yyyy, имей уважение корректно спеллить ник адресата, особенно если ты обращаешься за помощью.

Классическая модель репликации, существующая в SQL Server с незапамятных времен, как раз и предполагает синхронизацию изменений. Сначала мы синхронизируем мгновенный снимок данных (snapshot) на стороне подписчика, а потом накатываем на него изменения с той или иной степенью периодичности (в идеале - как только они происходят). Ненадежный канал связи не является здесь препятствием, п.ч. изменения сидят в distribution db до тех пор, пока не будут переданы подписчику. Что такое изменение. Грубо говоря, это тот самый оператор insert, update, delete, к-й произошел на издателе. Стало быть, размер одного изменения, к-е требуется передать, это десятки-сотни байтов. Поэтому понятно, что наибольший траффик придется на передачу начальной синхронизации. В SQL Server snapshot можно скинуть на внешний носитель, привезти подписчику на оленях и ручками синхронизировать. Если твой вопрос состоит в том, можно ли, скажем, за день копить все изменения на издателе, потом свалить их на ленточку и аналогично доставить и накатить вручную, то ответ однозначно нет, п.ч. это изврат. В моей практике одна довольно интенсивно обновляющаяся базуля жила и реплицировалась по 9600. Это соответствовало ситуации, дай Бог памяти, 20-30 пользователей в филиале. Как говорится, настоящих буйных мало, вот и траффик небольшой. Мне кажется, что у тебя в плане пользователей положение дел еще скромнее, так что все, что они с БД творят, в твою пропускную способность уляжется. Я могу, конечно, ошибаться, но если у тебя на 1200 сидят больше 5-ти юзерей, то какой же ты, нафиг, DBA, что довел до такого? Иди к начальству, бери его за жабры и требуй адекватный канал. Оперируй преимущественно доступными начальству категориями, не ругайся техническими терминами и вообще будь проще.

Очевидно, что штатными средствами нет, п.ч. здесь слишком много вещей, специфичных для SQL Server. Как, напр., log reader будет читать log через OLE DB, если нет такой буквы в этом слове? Для публикации данных из OLE DB-источника в SQL Server Вам придется написать специальную приблуду, к-я будет отлавливать изм-я в источнике и притворяться дистрибутором для SQL Server при помощи Replication Distributor Interface (см. пример в BOL -> Programming Replication from Heterogeneous Data Sources). C гетерогенными подписчиками ручного труда меньше - SQL Server может реплицировать данные в любые OLE DB-источники, но Вы должны понимать, что это простейшая модель безо всяких наворотов типа Updating или Queued Subscriber, п.ч. непонятно, напр., как повесить триггер на, скажем, текстовый файл.

Вручную синхронизация выполняется следующим образом.
После того, как отработал агент подготовил snapshot (см. BOL -> Snapshot Agents), Вы берете все файлы, что он создал в соответствующем каталоге (см. BOL -> Exploring Snapshots), переносите на подписчика и применяете их там (см. BOL -> Applying the Initial Snapshot). Напр., в файле с расширением .sch лежит скрипт, создающий объекты тиражирования. Его можно открыть и выполнить в Query Analyzer на подписчике. В файле с расширением .bcp лежат сами данные. Их нужно скопировать в созданные объекты при помощи утилиты bcp (см. BOL -> bcp Utility). Иными словами, делаете ручками все то, что при передаче через LAN или ftp за Вас делает Distribution Agent (см. BOL -> Distribution Agents).

PS. Уважаемый Yyyy (и не только). Я не заставляю вас читать документацию. Но давайте вы не будете заставлять меня вам ее пересказывать.

Исполать тебе, мил человек, на добром слове. А то народишко вконец наглость потерял. Уже называют меня не величайшим, а просто выдающимся. Прикинь, говорят, будто я подвижник, мученик, но не святой (почетный). Обижают нашего славного, нашего рубаху-парня, как я его называю, нашего королька. Впредь предлагаю титуловать меня просто "Великий и могучий утес с ногой на небе... или на земле? Черт, не помню. Живущий пока это... Пока не исчезнут машины".

Теперь, разобравшись с культом деда Маздая, поговорим о деле.
Эпиграф: "Мы работаем, как дилетанты. Как авторы любительских писем: 'Дорогие ученые. У меня который год в подполе происходит подземный стук. Объясните, пожалуйста, как он происходит'. Так нельзя. Система нужна."
Я целиком поддерживаю Александра Гладченко и присоединяюсь к его просьбе ценить не только свое время. Нам всем кажется, что мы говорим понятно и все вокруг, разумеется, в курсе моей проблемы, с которой я трахаюсь уже полдня, а как же иначе. Увы. Своих проблем хватает у каждого. Либо народ грешит деталями и присылает скрипт на полмега, абсолютно невоспроизводимый на сторонней тачке, в котором сразу отпадает охота ковыряться, потому что чтобы его постичь, требуется время, многократно превышающее время ответа на вопрос. Либо ударяется в другую крайность и формулирует проблему слишком обще, так что только многократные итерации способны прояснить суть проблемы. Я поражаюсь энтузиазму Александра в недавнем вопросе про репликацию со 100%-й загрузкой, однако стоило ли отвечать, зная, что это все равно будет гаданием на кофейной гуще. Если нет умения / желания грамотно описать проблему, пусть обращаются в техподдержку или в Microsoft Consulting и платят деньги в том числе и за то время, пока специалист будет въезжать в коряво поставленную задачу. Короче, я не собираюсь долго занудствовать, message, который я хотел донести, очень простой: garbage in - garbage out.

PS. За неимением собственного красноречия пришлось позаимствовать у классиков: Е.Шварц ("Обыкновенное чудо") и братья Стругацкие ("Попытка к бегству", "Понедельник начинается в субботу").