← На главную

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

Природа ошибки и механизм работы платформы 1С

Сообщение «В данной транзакции уже происходили ошибки» не является первопричиной проблемы. Это вторичная реакция платформы 1С. Когда внутри транзакции СУБД (вызванной явно методом НачатьТранзакцию() или неявно при записи объекта) происходит исключительная ситуация, платформа переводит текущую транзакцию в состояние Rollback-only (только для отмены).

Если разработчики применили конструкцию Попытка ... Исключение, перехватили исходное исключение, но не выполнили откат текущей транзакции через ОтменитьТранзакцию(), любое следующее действие с базой данных (запись константы, чтение реквизита, фиксация ошибки в служебном регистре) вызывает повторный сбой с текстом о том, что в транзакции уже был зарегистрирован сбой. Вложенных транзакций на уровне СУБД в платформе 1С нет — повторные вызовы НачатьТранзакцию() лишь увеличивают счетчик вложенности, и сбой во внутреннем блоке делает невозможным сохранение всех изменений внешнего блока.

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

Шаг 1. Локализация первопричины через журнал регистрации и отладчик

Для поиска реального сбоя выполним диагностику:

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

Шаг 2. Повторная передача файла обмена и обновление конфигурации

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

1. В центральном узле (ЦУ) выполним повторную выгрузку сообщения обмена.
2. В подчиненном узле загрузим полученное сообщение через конфигуратор или обработку обмена данными.
3. Выполним обновление конфигурации базы данных (клавиша F7).
4. Запустим сеанс в режиме 1С:Предприятие и дождемся завершения процедур обновления.

Шаг 3. Принудительный запуск обработчиков обновления БСП

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

/C ЗапуститьОбновлениеИнформационнойБазы

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

Шаг 4. Очистка кэша и тестирование базы данных

Рассинхронизация кэша метаданных часто провоцирует сбои при обращении к измененным реквизитам. Выполним регламентные процедуры очистки и проверки:

1. Удалим временные файлы платформы в каталогах AppData\Local\1C\1cv8 и AppData\Roaming\1C\1cv8 на компьютере пользователя.
2. В конфигураторе подчиненного узла откроем меню Администрирование -> Тестирование и исправление.
3. Отметим пункты «Реиндексация таблиц информационной базы», «Проверка логической целостности информационной базы» и «Проверка ссылочной целостности», после чего запустим процесс проверки.

Шаг 5. Ручное выравнивание конфигурации через отвязку узла РИБ

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

1. В центральной базе через меню Конфигурация -> Сохранить конфигурацию в файл выгрузим файл конфигурации .cf актуальной версии.
2. В подчиненной базе запустим внешнюю обработку или откроем клиентское приложение и программно снимем привязку к центральному узлу: ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
3. В конфигураторе подчиненной базы выполним команду Конфигурация -> Загрузить конфигурацию из файла, указав полученный файл .cf, и применим изменения (F7).
4. Запустим подчиненную базу в режиме 1С:Предприятие, чтобы процедуры обновления данных успешно завершились без механизмов блокировки РИБ.
5. После завершения обновления восстановим связь подчиненного узла с главным, выполнив код:
   Скопировать код

   
   // Вместо "ИмяПланаОбмена" укажем имя плана обмена РИБ, вместо "КодЦУ" - код главного узла
   ГлавныйУзелСсылка = ПланыОбмена.ИмяПланаОбмена.НайтиПоКоду("КодЦУ");
   ПланыОбмена.УстановитьГлавныйУзел(ГлавныйУзелСсылка);
   

После восстановления привязки узел РИБ продолжит работу в штатном режиме, а последующие обмены данными будут проходить без транзакционных ошибок.