У меня очень странная проблема с пользовательской обработкой конфликтов с использованием Sync Framework.Учитывая следующую простую структуру базы данных:
CREATE TABLE [dbo].[Container](
[Id] [uniqueidentifier] NOT NULL DEFAULT newid(),
[LocationId] [uniqueidentifier] NULL REFERENCES [dbo].[Location],
.....
)
CREATE TABLE [dbo].[Location](
[Id] [uniqueidentifier] NOT NULL DEFAULT newid(),
[Name] [varchar](100) NULL,
.....
)
Теперь предположим, что в моей базе данных есть контейнер.На клиенте я установил его LocationId в одно значение.На сервере я установил другое значение.Я пытаюсь выполнить синхронизацию, и, как и ожидалось, я получаю ApplyChangeFailedEvent типа LocalUpdateRemoteUpdate.
В рамках процесса разрешения конфликта я хотел бы отобразить информацию о конфликте для пользователя и попросить его выбрать правильныйместо нахождения.Чтобы сделать это, мне нужно прочитать Location, соответствующий LocationId как на стороне клиента, так и на стороне сервера, и вот тут возникает проблема. Мой тайм-аут чтения, потому что среда синхронизации, похоже, заблокировала таблицу.sp_lock2 показывает, что в таблице Location есть блокировка типа 'X'.
Кикер в том, что это происходит только для некоторых столбцов внешнего ключа в некоторых таблицах,Большинство из них в порядке, но некоторые из них вызывают исключительную блокировку каждый раз.
Если у кого-то есть идеи о том, что конкретно вызывает исключительную блокировку во время разрешения конфликта, или о том, что я могу сделать, чтобы избежать этого или работатьвокруг было бы очень признательно.Если я не могу надежно читать данные из базы данных во время разрешения конфликта, моя стратегия обработки конфликтов в значительной степени бессмысленна.
ОБНОВЛЕНИЕ: Похоже, я был немного неправ.Он не блокирует всю таблицу, только записи, вовлеченные в конфликт.Я могу сделать SELECT * FROM Location WHERE ID = (идентификатор записи, не вовлеченной в конфликт), я просто не могу сделать SELECT * FROM Location WHERE Id = (id записи конфликта).