Здравствуйте!
При формировании отчетов иногда вылетает такого рода ошибка:
Отчет.ВзаиморасчетыПоДокументам(244)}: Ошибка при вызове метода контекста (Записать): Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки из-за ожидания сессии 1217 ЭлементСправочника.Записать(); по причине: Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки из-за ожидания сессии 1217

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

XenoXДве разные транзакции не могут менять одни и те же данные(в контексте 1С), последняя всегда отвалится с ошибкой.
Что за необходимость такая писать что-то в справочники при формировании отчета?
Разобрав код понял, что дело происх сл. образом: в табл часть определенного элемента справочника засовывается набор данных и потом из нее берутся данные для отчета а сам элемент служит параметром для текста построителя... вот так ...
насколько я понял... не пересмотрев алгоритм формирования отчетов конффликт блокировок не снять?

XenoX,
Спасибо, буду думать.

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

nicktcherGoToNextИ еще вопрос... я правильно понимаю что если нчеть в транзакции что либо записывать в справочник... попытка в этот момент обратиться к справочнику будет как раз блокироваться этой транзакцией?

Что это за дурацкий отчет такой у Вас, типа использует какой-то справочник в качестве "кэша"? Забавно. Вообще не должно быть блокировок, если каждый раз создается новый элемент справочника, а читаются уже записанные. Хотя в SQL-базе возможны блокировки смежных элементов таблиц.
Вы посмотрите, может у вас это справочник уже "разросся" ацки)))?

Советую всё таки исправить отчет. Если он действительно действует так как Вы описали, это убогое и корявое решение. Замените сброс данных в ТЧ спр-ка обычной табл.значений. А когда они понадобятся, извлекайте из этой таблицы. Тогда блокировок быть не должно
Справочник пуст.
транзакции начинаются непосредственно перед методом записать, и в табл. часть грузятся большие объемы... т. е. это может занять длительное время... может быть отваливается из -за этого...

XenoXGoToNextтранзакции начинаются непосредственно перед методом записать, и в табл. часть грузятся большие объемы... т. е. это может занять длительное время... может быть отваливается из -за этого...
А зачем... обычтно в рамках транзакций выполняют НЕСКОЛЬКО действий, сбой в одном из которых нарушает логику всей операции... в момент записи итак стартует транзакция, и либо запись произойдет либо нет...
Зачем не знаю, сейчас разбираюсь со сложившейся ситуацией... а в транзазакции три действия :
- запись элемента справочника
- добавление параметра в построитель отчета
- формирование отчета
а затем идет ОтменитьТранзакцию(); ... и справочник отчищается...
вот такие вот выкрутасы

XenoXGoToNext
вот такие вот выкрутасы
Дурдом ОДНАКО
наверно создатель этого чуда имеет богатый внутренний мир
можно было б записать элемент и после отработки удалить... если никак иначе... бред

ARIST_A,

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

ARIST_A,
Нет, данное действо делалось разработчиками давно ушедшими...