Синхронизация данных с мобильных устройств / КПК + SQL Server

Question

Нужен небольшой совет здесь. Мы занимаемся разработкой Windows Mobile, используя платформу .NET Compact и SQL CE для мобильных устройств, а также центральную базу данных SQL 2005 в офисах клиентов. В настоящее время мы синхронизируем данные с использованием технологии репликации слиянием.

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

Итак, мне просто интересно, если репликация была способом синхронизации данных или есть более надежные методы? Я думал, может быть, веб-сервисы или что-то в этом роде. Что вы, ребята, используете для реализации этого решения?

Dave

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

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

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

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

Answer 4

Мы работаем над аналогичной ситуацией, но наша занимается разработкой инструмента, который работает в автономной модели и работает на рабочем столе 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, но для нас это было быстрое решение проблемы.

Answer 5

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

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

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