Есть справочник (Детали), в котором часто создаются новые элементы и перезаписываются существующие. Пользователей в базе работает много и иногда получается так, что почти одновременно записываются десятки элементов этого справочника.
Если при этом попытаться выполнить простой запрос:
ВЫБРАТЬ
    Детали.Ссылка
ИЗ
    Справочник.Детали КАК Детали
ГДЕ
    Детали.Прибор = &Прибор
    И НЕ Детали.ПометкаУдаления
Возникает конфликт блокировок на строке:
Результат = Запрос.Выполнить();

Ошибка при вызове метода контекста (Выполнить): Ошибка выполнения запроса "Конфликт блокировок при выполнении транзакции:
Microsoft OLE DB Provider for SQL Server: Lock request time out period exceeded.
HRESULT=80040E31, SQLSrvr: Error state=34, Severity=10, native=1222, line=1
"'
Можно ли как-то избежать конфликта блокировок?

Транзакция где начинается?

(1) Явных транзакций нигде нет.

(0)Юзай управляемые блокировки

(2) ну а не явных? Спрошу по другому, в обработке проведения запрос?

(0) Если запрос выполняется вне транзакции, блокировок быть не может. Если в транзакции, нужно честно признаться, где именно выполняется запрос.

(3) Хотелось бы оставить автоматический режим.
(4)(5) Запрос вызывается из подписки на событие ПриЗаписи.

(6) Но при записи другого справочника, не этого.

(6) А говоришь, транзакций нет...

(6) Юзай событие ПередЗаписью

(6) Юзай ПередЗаписью если возможно

(0) реквизит Детали.Прибор индексирован?

(7) определись уже, этого или другого?

(11) Да, индексирован.
(12) Подписка срабатывает при записи справочника Приборы. Нужно при пометке на удаление элемента справочника Приборы помечать на удаление все детали, связанные с этим прибором.
В подписке проверяется, установлена ли пометка на удаление и если установлена, выбираются детали запросом из (0) и помечаются на удаление.

(0) какие действия пользователей в транзакциях, которые обновляют детали, выполняются долго? Т.е. что блокирует справочник и провоцирует таймауты?

(0) читай данные перед записью, а обрабатывай при записи

(15) Тогда данные будут не консинстентными.

(15) Скорее всего не поможет. И "ПередЗаписью" и "ПриЗаписи" выполняются уже в транзакции записи

(13) Сделай справочник "Приборы" подчиненным справочнику "Детали" и можно удалить подписку.

(18) Детали могут быть не связаны с прибором.

(0) кстати здесь в запрос нужно добавить ДЛЯ ИЗМЕНЕНИЯ

(19) Тогда зачем их удалять?

(21) Те, которые связаны нужно удалить.

(19) Извиняюсь перепутал. Надо сделать справочник "Детали" подчиненным справочнику "Приборы".

(22) Они не могут быть связаны одновременно с более чем одним справочником?

(20) Это вызовет блокировку этих данных. Я не понимаю, это действительно, может помочь?
(23) Такой вариант не подойдет. Детали могут быть не связаны с прибором.
(24) Нет, после того, как их связали с каким-то прибором, с другими приборами они не могут быть связаны и если прибор удаляется, удаляются и детали.

(25) вданной ситуации это скорее всего не поможет, но поможет избежать возможных дедлоков
есть общая рекомендация:
если в транзакции данные считываются, а потом меняются то их нужно блокировать на этапе чтения

Не раскрыт остался вопрос в том откуда возникает блокировка в запросе по одному прибору. Возможно система пытается заблокировать весь справочник, а не по прибору. Возможно условие по пометке удаления убрать?

(27) Из запроса условие по пометке убрать? В общем-то да, можно. Из-за него может быть блокировака?

Или скуль при записи ставит блокировку на всю таблицу. Там вообще сколько записей в таблице?

(25) при каком сценарии работы пользователей могут перезаписываться детали одного прибора?

(28) может в каких-то еще транзакциях идут обращения к деталям?

Запрос в транзакции ставит S-блокировку на справочник детали. Она может помешать только X-блокировке при записи той же детали, которая была прочитана (а не получена) SQL-запросом.

Надо бы ЦУПом посмотреть список ожиданий на блокировках и заблокированные и блокирующие запросы.

(29) На данный момент там 1 592 492 записей.
(30) Связанные только при пометке на удаление перезаписываются, а в несвязанных приборы указывают, когда связывают.
(31) Вроде бы нет нигде больше.

(33) если нет пересечений перезаписей деталей по одному прибору от разных пользователей, то возможно где то есть избыточное сканирование таблицы деталей в транзакции

лучше конечно инструментами все это анализировать

+(33)  хотя нет, тут сканирование мешать не должно

Кстати, а для чего нужны вот эти поля в конструкторе?
Обязательно в правое поле добавлять данные?
http://f6.s.qip.ru/gbw3dlzp.png

(0)
"Можно ли как-то избежать конфликта блокировок?" - можно, если понять тип блокировки в MS SQL. Они бывают: TAB, KEY, RID, PAGE и прочие. Когда сможете это понять, то конкретно для каждого типа свой механизм действий.

(36) Видимо, когда несколько таблиц в запросе, можно указать конкретную таблицу.

(38) и только по ней будут блокировки, иначе по всем в запросе

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