Конфликт блокировок при выполнении транзакции 1С: что это и как исправить

Ошибка «Конфликт блокировок при выполнении транзакции» — одна из самых частых проблем в многопользовательских базах 1С. Она означает, что два или более сеанса одновременно попытались изменить одни и те же данные, и платформа не смогла выполнить обе операции без нарушения целостности. Один сеанс был вынужден завершиться с ошибкой, чтобы второй мог корректно записать изменения.

Важно понимать: это не сбой программы и не повреждение базы. Блокировка — штатный механизм защиты данных. Проблема возникает тогда, когда конкурирующие обращения к одним записям становятся слишком частыми или транзакции выполняются слишком долго. Разовая ошибка обычно лечится повторным проведением документа, систематическая — требует анализа настроек и кода.

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

Что такое блокировка и почему возникает конфликт

Когда пользователь проводит документ или записывает элемент справочника, 1С открывает транзакцию — набор операций, которые должны выполниться целиком или не выполниться вовсе. На время транзакции платформа накладывает блокировки на затрагиваемые данные: записи регистров, строки таблиц, объекты справочников. Другие сеансы, которым нужны те же данные, вынуждены ждать.

Конфликт возникает в двух типовых ситуациях. Первая — превышение времени ожидания: сеанс ждал освобождения ресурса дольше установленного таймаута и был прерван. Вторая — взаимоблокировка (deadlock): сеанс А держит ресурс, нужный сеансу Б, а сеанс Б держит ресурс, нужный сеансу А. СУБД в этом случае принудительно завершает одну из транзакций, выбирая «жертву».

Типичные причины ошибки в рабочей базе

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

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

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

Что делать пользователю при появлении ошибки

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

Порядок действий простой. Подождите 30–60 секунд и повторите операцию. Если ошибка повторяется, уточните у коллег, не работает ли кто-то с тем же контрагентом, складом или набором товаров. При массовой ошибке у нескольких сотрудников сразу сообщите администратору — вероятно, идёт тяжёлый фоновый процесс, который лучше дождаться или перенести.

Не стоит многократно нажимать «Провести» подряд без паузы: каждая попытка создаёт новую транзакцию и увеличивает очередь ожидания, усугубляя ситуацию для всех пользователей.

1. 1
   Закройте сообщение об ошибке и сохраните введённые данные, скопировав важные значения
2. 2
   Подождите 30–60 секунд и повторите проведение документа
3. 3
   Если ошибка повторилась — проверьте, не редактирует ли коллега тот же объект
4. 4
   При массовой ошибке сообщите администратору и дождитесь завершения фоновых процессов
5. 5
   После успешного проведения убедитесь, что документ отразился в отчётах корректно

Диагностика для администратора

Первый инструмент администратора — журнал регистрации. Отфильтруйте события по ошибке с текстом «Конфликт блокировок» и посмотрите, какие пользователи, объекты и моменты времени фигурируют чаще всего. Совпадение по времени с фоновыми заданиями почти всегда указывает на виновника.

В клиент-серверном варианте используйте консоль кластера серверов 1С: там видны активные сеансы, соединения и текущие блокировки. Дополнительно полезен технологический журнал с включёнными событиями TLOCK, TDEADLOCK и TTIMEOUT — он показывает, какие именно таблицы и записи конкурируют. На стороне СУБД (MS SQL Server, PostgreSQL) аналогичную картину дают системные представления и мониторы блокировок.

Проверьте настройку режима управления блокировками: «Конфигуратор» → «Администрирование» → «Параметры информационной базы». Для клиент-серверных баз рекомендуется режим «Управляемый» — автоматический режим блокирует избыточно широкие диапазоны данных и является частой причиной конфликтов.

Способы устранения и профилактики

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

Вторая группа мер — организационные. Разнесите по времени тяжёлые операции: обмены, перепроведение, закрытие месяца и загрузку данных планируйте на нерабочие часы. Ограничьте одновременный запуск нескольких экземпляров одного регламентного задания. Договоритесь с пользователями о разделении зон ответственности, чтобы над одним складом или контрагентом не работали одновременно несколько человек в режиме массового проведения.

Третья группа — оптимизация кода и процессов. Для доработанных конфигураций проверьте длительность транзакций: запись в цикле, обращения к СУБД внутри транзакции, вызовы внешних сервисов до фиксации — всё это удлиняет удержание блокировок. В регистрах накопления включите разделение итогов там, где это применимо, и пересмотрите индексы по измерениям, по которым чаще всего идут записи.

Сравнение подходов

Автоматический режим блокировок

Не требует изменений в коде, но блокирует избыточно много данных — подходит только для небольших баз с малым числом пользователей

Управляемый режим блокировок

Минимизирует конфликты и рекомендован для клиент-серверных баз, но требует совместимости конфигурации и грамотной расстановки блокировок в коде

Разнесение нагрузки по времени

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

Частые ошибки при борьбе с блокировками

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

Вторая ошибка — лечить симптом вместо причины: увеличивать таймаут ожидания блокировки на сервере СУБД. Пользователи перестают видеть ошибку, но вместо неё получают «зависания» на десятки секунд, потому что сеансы теперь дольше ждут в очереди. Таймаут — не решение, а отсрочка.

Как проверить, что проблема решена

После внесённых изменений понаблюдайте за базой несколько рабочих дней. Критерий успеха — исчезновение массовых обращений пользователей и уменьшение числа событий с текстом «Конфликт блокировок» в журнале регистрации. Единичные случаи допустимы и не требуют реакции.

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

Контрольные точки

Как проверить результат

Журнал регистрации

Норма

События «Конфликт блокировок» единичны

Тревожный признак

Ошибки повторяются ежедневно у разных пользователей

Скорость проведения документов

Норма

Документ проводится за привычное время без пауз

Тревожный признак

Проведение «подвисает» на десятки секунд

Фоновые задания

Норма

Обмены и регламентные операции идут вне рабочих часов

Тревожный признак

Тяжёлые задания запускаются в часы пик

Частые вопросы

Приведёт ли конфликт блокировок к потере данных?

Нет. Транзакция, столкнувшаяся с конфликтом, полностью откатывается: база остаётся в состоянии, как до попытки записи. Потеряться могут только введённые, но не записанные пользователем данные в открытой форме.

Почему ошибка возникает чаще в конце месяца?

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

Нужно ли что-то делать, если ошибка появилась один раз?

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

Поможет ли переход на клиент-серверный вариант работы?

Сам по себе — нет, но клиент-серверный вариант вместе с управляемым режимом блокировок даёт инструменты для существенного снижения конфликтов. В файловой базе блокировки по своей природе грубее, поэтому при росте числа пользователей переход на серверную архитектуру оправдан.

Может ли конфликт вызывать одна конкретная доработка конфигурации?

Да. Нетиповой код с длительными транзакциями, записью в цикле или отсутствием явных управляемых блокировок — частый источник проблем. Если ошибки начались после обновления или внедрения доработки, проверяйте в первую очередь её.