Обновления и удаления SyncFramework 2.1, похоже, не применяются должным образом

Question

Я синхронизирую SQL Server 2008 с ~6 клиентами SQL Server 2008 Express (все, что мне кажется R2), используя SyncOrchestrator или, в частности, используя http://code.msdn.microsoft.com/windowsdesktop/Database-SyncSQL-Server-e97d1208 как база с небольшими изменениями. Насколько мне известно, это означает, что все соединения являются узлами или узлами.

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

Область "только загрузка" использует Guids, так как, к счастью, я могу контролировать эту часть базы данных, и не было бы никакого способа, чтобы 10 клиентов, использующих одинаковое начальное число идентификаторов, могли правильно синхронизироваться с сервером. Обе области используют подготовку по умолчанию с массовыми вставками и целыми 9 ярдами, поэтому на стороне подготовки не должно быть ничего, что я испортил бы.

Я изначально настроил все, не используя PerformPostRestoreFixup И исходная база данных была бы вручную синхронизирована с операторами вставки с хоста. Это выглядело нормально, но обновления и удаления, похоже, никогда не применялись. Вы можете спокойно проигнорировать это (используется только для исторической точности и для подтверждения моей неумелости), поскольку я затем использовал проекты баз данных VS2010, чтобы перестроить базу данных до схемы только и синхронизировать. Затем я использовал описанные здесь шаги (http://social.microsoft.com/Forums/br/syncdevdiscussions/thread/9ac6d1a1-1565-4b82-a8d8-3d4a9ff5d07b) (синхронизация, резервное копирование, восстановление, вызов выполнения mpostrestorefixup, синхронизация на клиентах x) и на моем устройстве разработчика, где я все это настраиваю, я видел обновления и удалял просто отлично. Когда я развертываю это на x-клиентах, я не вижу зеркала базы данных, как мне кажется.

Начальная синхронизация будет жаловаться и попытаться синхронизировать все записи снова. Я считаю, что это ожидается. Во время события ApplyChangeFailed на клиенте я установил для ApplyAction.RetryWithForceWrite все, кроме DbConflictType.ErrorsOccurred. Это может быть источником проблем, так как я изначально думал, что это должно быть сделано, чтобы заставить изменения перейти к клиенту. Я хочу, чтобы сервер всегда побеждал в этом сценарии, но во время трассировки я всегда вижу фразу "Локальные выигрыши" во время массовых вызовов вставки / обновления. Возможно, я вижу ошибку до повторного применения, но на это неловко смотреть.

Единственная проблема, с которой я, похоже, сталкиваюсь - это только объем загрузки. Первоначальной клиентской базе данных уже около недели, и если я использую шаги Performpostrestorefixup, я не вижу ни одного из обновлений, которые были применены между сейчас и потом, как мне кажется, я должен. Как будто SyncFx почти предпочитает пустую базу данных на стороне клиента, чтобы начать первоначальную синхронизацию, тогда все обновления, кажется, применяются просто отлично без запуска событий ApplyChangesFailed.

Если кто-то видел это раньше или имеет подсказку, куда идти, я был бы очень признателен. Мой мозг зажегся, пытаясь определить, что происходит. Мое последнее желание - развернуть пустые базы данных на всех клиентах и ​​заставить их начать синхронизацию. У меня не было проблем с этим на стороне разработчика, но я могу протестировать только одного другого клиента, чтобы узнать, изменит ли это что-то другое. Кроме того, я не знаю, что делать, кроме как продолжать выполнять ручную синхронизацию, которая полностью победила бы эту цель. Я думал, что PerformPostRestoreFixup решит проблему полностью, но у меня, похоже, есть те же проблемы с или без него, или, возможно, я не смотрю на то, что мне нужно.

Спасибо

Answer 1

Я хотел сообщить и закрыть запись со своими выводами.

Когда я развертывал предварительно настроенную клиентскую базу данных, я часто получал события ApplyChangeFailed в виде этого журнала:

"[05:30:41 PM] - ApplyChange Failed: TableName:, Stage: ApplyingInserts, ConflictType: LocalInsertRemoteInsert, Action: RetryWithForceWrite"

Это то, что я ожидал, так как он попытался повторно вставить данные, которые уже есть. То, к чему это должно было быть изменено, было оператором обновления во время RetryWithForceWrite, но я обнаружил, что данные не обновлялись с тем, что передавалось.

Как только я запустил каждый клиент с полностью пустой базой данных и подготовил ее локально, все эти ошибки исчезли. Как будто каждый клиент ожидает какой-то уникальный идентификатор, который он только устанавливает. Я также использую сборки x64 по сравнению с x86, которые могут иметь некоторые результаты или не иметь никакого отношения к результатам. Хотелось бы определить, что именно произошло, но кажется, что в случае сомнений и, когда это возможно, начиная с абсолютного нуля и позволяя синхронизации заполнить данные, ваш самый безопасный вариант.