Синхронизация данных Mobile / PDA + SQL Server

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

Если вы более конкретно говорите о том, что «как правило, немного ненадежно», то, возможно, вы получите более полезный совет. Как это все, что я могу сказать, у меня не было проблем с этим.

РЕДАКТИРОВАТЬ: учитывая ваш ответ ниже, я просто скажу, что вы, безусловно, можете использовать настраиваемую репликацию, которая использует SSIS или какой-либо другой метод, но определенно есть магазины, успешно использующие репликацию в производственной среде.

ну, у нас дважды возникала ошибка, что было настоящим исправлением боли: -

Вставить не удалось. Он конфликтовал с ограничением проверки диапазона идентификаторов в базе данных egScheduler, реплицированной таблице dbo.tblServiceEvent, столбце serviceEventID. Если столбец идентификаторов автоматически управляется репликацией, обновите диапазон следующим образом: для издателя выполните процедуру sp_adjustpublisheridentityrange; для подписчика запустите агент распространителя или агент слияния.

Когда мы попытались запустить хранимую процедуру, она испортила идентификаторы, поэтому теперь, когда мы пытаемся синхронизировать, она выдает следующую ошибку в мониторе репликации.

Невозможно повторно применить строковую операцию из-за нарушения целостности. Проверьте фильтр публикаций. [,,, Table, Operation, RowGuid] (Источник: MSSQLServer, номер ошибки: 28549)

У нас также было несколько проблем, когда моментальные снимки становились недействительными, но их было относительно легко исправить. Однако все это заставляет меня задуматься, является ли репликация лучшим методом для того, что мы пытаемся сделать здесь, или есть более простой метод. Это то, что вызвало мой первоначальный вопрос.

Мы работаем над аналогичной ситуацией, но наша компания занимается программированием инструмента, который работает в автономной модели и работает на рабочем столе Windows ... Мы используем SQL Server Compact Edition для клиентов и Microsoft SQL Server 2005 с веб-сервис для серверного решения.

Чтобы включить службы синхронизации, мы изначально начали с создания нашей собственной инфраструктуры синхронизации, но после многих проблем с поддержанием синхронизации этой структуры с остальной системой мы решили использовать Microsoft Synchronization Framework. (http://msdn.microsoft.com/en-us/sync/default.aspx для справки). Наши первоначальные требования заключались в том, чтобы сделать приложение таким же простым в использовании, как и установка других пакетов, таких как Intuit QuickBooks, и я думаю, что нам это практически удалось.

У Synchronization Framework от Microsoft есть свои взлеты и падения, но единственное плохое, что я могу сказать на данный момент, - это ужасающая документация.

Сейчас мы обсуждаем вопрос, продолжать ли его использовать или вернуться к поддержке нашей собственной подсистемы синхронизации. YMMV, но для нас это было быстрое решение проблемы.

Вы определенно расширяете пределы стабильности для CE, не так ли?

Когда я это сделал, я обнаружил, что необходимо добавить изрядную долю терпимости к конфликтам, не думая об этом столько, сколько о синхронизации как об одновременном асинхронном сборе данных с периодическими взаимными обновлениями и / или обновлениями. В частности, я всегда избегал использования столбцов идентификаторов для чего-либо. Если вы можете строго придерживаться истинных первичных ключей, основанных на реальных (не суррогатных) данных, это упростит задачу. Иногда хорошо работает ПК, содержащий SourceUnitNumber и временную метку.

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

Отправьте ответ, как это получается. Мне интересно увидеть любую надежную технологию Microsoft, которая поможет в этом.

TomH & le Dorfier: Я думаю, что часть нашей проблемы заключается в том, что мы позволяем клиенту вставлять большое количество строк в одну из реплицированных таблиц с полем идентификации. Это приложение для планирования, которое может автоматически выполнять несколько задач до определенного месяца / года. Один из случаев, когда это не удалось, был примерно в то время, когда они вводили в таблицу 15000 строк. Мы постараемся расширить диапазон идентификации.

Фреймворк синхронизации звучит интересно, но похоже, что он страдает той же проблемой, что и репликация из-за плохой документации. Попытка найти помощь по репликации - это своего рода кошмар, и я не уверен, что хочу, чтобы мы перешли к чему-то с аналогичными проблемами. Желаю, чтобы M'soft перестал выпускать вещи, которые, похоже, поддерживают бета-версию ПО!