Нет транзакции при синхронизации 1С: что это и как исправить

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

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

Материал подходит для файловых и клиент-серверных баз на платформе 1С:Предприятие 8.3. Действия описаны для типовых механизмов обмена; если у вас самописная синхронизация, логика диагностики сохраняется, но конкретные места проверки будут зависеть от кода.

Что означает ошибка «нет транзакции»

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

Когда код обмена после этого пытается выполнить «ОтменитьТранзакцию()» или «ЗафиксироватьТранзакцию()», платформа сообщает, что активной транзакции нет. В журнале регистрации это выглядит как цепочка: сначала реальная ошибка (например, «Конфликт блокировок» или «Ошибка СУБД»), а следом — «Транзакция не активна» / «Нет транзакции». Исправлять нужно первое событие, второе уйдёт само.

Типичные причины появления ошибки

Практика показывает, что первопричины группируются в несколько устойчивых категорий. Понимание категории сразу сужает круг проверок.

• Повреждённое или «тяжёлое» сообщение обмена. Файл обмена содержит объект, который не может быть записан: ссылка на несуществующий объект, нарушение уникальности, некорректные данные после доработок.
• Конфликты блокировок. Параллельная работа пользователей или фоновых заданий блокирует те же записи, что и обмен. Особенно актуально для клиент-серверных баз с интенсивной работой.
• Ошибки СУБД и инфраструктуры. Переполнение диска, разрыв соединения с сервером 1С или SQL, тайм-ауты при больших пакетах.
• Доработки конфигурации. Подписки на события записи, обработчики «ПриЗаписи», которые вызывают исключения при загрузке данных из обмена.
• Несовпадение версий конфигураций в узлах обмена после обновления одной из баз.

Пошаговая диагностика

Начинайте с журнала регистрации: откройте его с отбором по времени обмена и уровню «Ошибка». Найдите самое раннее событие в цепочке — именно оно указывает на причину. Обратите внимание на поля «Данные» и «Комментарий»: там часто указан объект, на котором произошёл сбой.

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

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

1. 1
   Откройте журнал регистрации и найдите первую ошибку в цепочке по времени обмена
2. 2
   Посмотрите протокол обмена: последний обработанный объект и правило конвертации
3. 3
   Проверьте файл сообщения обмена на целостность (размер, структура XML)
4. 4
   Проверьте свободное место на дисках сервера и доступность СУБД
5. 5
   Повторите обмен в монопольном режиме или при минимальной нагрузке
6. 6
   Если ошибка привязана к объекту — исправьте или исключите его из выгрузки

Как исправить типовые сценарии

Проблема в конкретном объекте

Если протокол показывает, что загрузка падает на конкретном документе или элементе справочника, откройте этот объект в базе-приёмнике. Частые ситуации: дубли по коду или номеру, заполненное поле, которое в новой версии конфигурации стало обязательным, битая ссылка. Исправьте объект вручную или измените данные в источнике и выгрузите заново.

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

Конфликты блокировок

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

Зависший обмен и повторная регистрация

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

Особенности для файловых и клиент-серверных баз

В файловых базах ошибка «нет транзакции» чаще связана с повреждением структуры базы после аварийного завершения (выключение питания, обрыв сетевого диска). Дополнительно к стандартной диагностике выполните тестирование и исправление информационной базы в конфигураторе — только после создания копии и при отсутствии активных сеансов.

В клиент-серверном варианте чаще виноваты тайм-ауты и блокировки СУБД. Проверьте логи SQL-сервера, наличие свободного места под tempdb и журналы транзакций, а также стабильность сети между сервером 1С и сервером СУБД. Большие пакеты обмена имеет смысл уменьшить, ограничив объём выгрузки за один сеанс.

Сравнение вариантов

Разбор и исправление проблемного объекта

Точечное решение, сохраняет целостность данных. Требует времени на анализ протокола

Исключение объекта из обмена

Быстро разблокирует обмен, но объект остаётся рассинхронизированным — нужен контроль

Повторная регистрация и полный обмен

Помогает при рассинхронизации номеров сообщений, но создаёт большой пакет и нагрузку

Профилактика повторения ошибки

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

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

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

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

Можно ли просто перезапустить обмен?

Можно, если ошибка была разовой — например, из-за временного разрыва сети. Если при повторном запуске ошибка возвращается на том же пакете, перезапуск бесполезен: нужно анализировать протокол и первичную ошибку в журнале регистрации.

Где найти протокол обмена в типовой конфигурации?

Откройте раздел с настройками синхронизации данных, выберите нужный обмен и перейдите по ссылке с предупреждением об ошибке или кнопке «Подробнее». Там отображаются события загрузки и выгрузки с указанием объектов, на которых возникли проблемы.

Опасна ли эта ошибка для данных?

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

Что делать, если обмен самописный и протокола нет?

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

Когда привлекать специалиста?

Если ошибка связана с повреждением структуры базы, ошибками СУБД на уровне сервера или если требуется сброс номеров сообщений и повторная регистрация большого объёма данных. Эти операции при неверном выполнении приводят к потере синхронизации, и опыт администратора здесь критичен.