«В данной транзакции уже происходили ошибки» в 1С: как найти первопричину

Почему сообщение о происходивших ошибках — вторичное

После ошибки ограничения уникальности, внешнего ключа, взаимоблокировки, тайм-аута или некорректного SQL PostgreSQL помечает текущую транзакцию как аварийную. До команды отката она больше не выполняет запросы. Платформа 1С при следующем обращении к данным получает сообщение в духе «current transaction is aborted» и показывает пользователю: «В данной транзакции уже происходили ошибки».

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

Как найти первое исключение выше в логе

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

• Журнал регистрации: отберите события по периоду, пользователю, приложению и сеансу; раскройте технические подробности первого события уровня «Ошибка».
• Технологический журнал: сопоставьте события по процессу, клиентскому идентификатору и времени; проверьте DBMSSQL/DBPOSTGRS, EXCP и CALL до вторичного сообщения.
• Лог приложения: сохраняйте ОписаниеОшибки() сразу в первой секции Исключение, пока контекст не потерян.

НачатьТранзакцию, Зафиксировать и Отменить: правильный шаблон

Транзакцию фиксируют только после успешного выполнения всего блока. Любое исключение сначала требует отмены, а затем должно быть передано вызывающему коду через ВызватьИсключение. Так код не продолжит запросы в уже испорченном контексте.

НачатьТранзакцию();
Попытка
    ДокументОбъект.Записать();
    ОбновитьСвязанныеДанные(ДокументОбъект.Ссылка);

    ЗафиксироватьТранзакцию();
Исключение
    ИнформацияОбОшибке = ИнформацияОбОшибке();
    ОтменитьТранзакцию();

    ЗаписьЖурналаРегистрации(
        "ОбменДанными.ОшибкаЗаписи",
        УровеньЖурналаРегистрации.Ошибка,
        , ,
        КраткоеПредставлениеОшибки(ИнформацияОбОшибке));
    ВызватьИсключение;
КонецПопытки;

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

Почему нельзя продолжать запросы после DB error

Перехват исключения в 1С не восстанавливает состояние транзакции на стороне СУБД. Конструкция, которая «проглотила» ошибку записи и перешла к следующему запросу, гарантированно маскирует полезную диагностику вторичным сообщением. После DB error допустимы только сбор уже доступной информации об ошибке, откат и выход из текущей операции.

// Ошибка: выполнение продолжается в той же транзакции
НачатьТранзакцию();
Попытка
    НаборЗаписей.Записать();
Исключение
    // Исключение проигнорировано
КонецПопытки;

// Этот запрос покажет вторичную ошибку транзакции
Результат = Новый Запрос("ВЫБРАТЬ ПЕРВЫЕ 1 Ссылка ИЗ Справочник.Номенклатура").Выполнить();
ЗафиксироватьТранзакцию();

Не пытайтесь «проверить, ожила ли база» дополнительным запросом. Отмените транзакцию, завершите текущий сценарий и только затем при необходимости запускайте новую операцию с начала.

Вложенные транзакции в 1С

Повторный вызов НачатьТранзакцию() внутри уже открытой транзакции не создаёт независимую точку сохранения, которую можно откатить отдельно. Вложенные вызовы увеличивают уровень транзакции, но ошибка на любом уровне влияет на общую транзакцию. Внутренняя процедура не должна считать, что её локальный ОтменитьТранзакцию() позволит внешнему коду безопасно продолжить работу.

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

Обработчики записи и проведения: где скрывается первопричина

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

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

Частые ошибки при исправлении транзакции в 1С

• Исправлять строку из последнего сообщения. Она часто корректна; первичное исключение находится выше в логе.
• Оставлять пустую секцию Исключение. Ошибка скрывается, а следующий запрос получает сообщение об аварийной транзакции.
• Фиксировать транзакцию после перехваченной ошибки. После DB error нужна отмена, а не попытка сохранить частичный результат.
• Вызывать ОтменитьТранзакцию() слишком поздно. Между исключением и откатом не должно быть запросов к базе.
• Открывать «внутреннюю» транзакцию как независимую. Вложенность 1С не изолирует её от внешней транзакции.
• Логировать только ОписаниеОшибки() последнего сбоя. Сохраняйте информацию о первом исключении и контекст операции.

Частые вопросы об ошибках внутри транзакции 1С