При переходе с устаревших релизов «1С:Бухгалтерии предприятия» (например, с версии 3.0.64.54 на 3.0.65.69 и выше) технические специалисты часто сталкиваются со сбоем на этапе обновления информационной базы в режиме «1С:Предприятие». Процесс прерывается критической ошибкой, связанной с заполнением справочника ИдентификаторыОбъектовМетаданных и регистрацией изменений на узлах планов обмена.
В этой статье мы подробно проанализируем, почему возникает эта проблема, разберем временный программный обход ошибки, изучим ее глубинную причину на уровне СУБД и рассмотрим безопасные методы полного восстановления работоспособности базы данных.
Сбой происходит после успешного обновления конфигурации в режиме Конфигуратора при первом запуске базы в режиме «1С:Предприятие». В процессе выполнения отложенных обработчиков обновления система выдает следующее сообщение об ошибке:
{Справочник.ИдентификаторыОбъектовМетаданных.МодульМенеджера(1713)}: Ошибка при вызове метода контекста (Записать) ТаблицаОбъект.Записать;
по причине: Ошибка при выполнении обработчика - 'ПередЗаписью'
по причине: {ОбщийМодуль.СтандартныеПодсистемыСервер.Модуль(902)}: Ошибка при вызове метода контекста (Добавить) Объект.ОбменДанными.Получатели.Добавить(Получатель);
по причине: Несоответствие типов (параметр номер '1')
Давайте разберем по шагам, что происходит в этот момент в коде системы. При записи метаданных срабатывает механизм подсистемы обмена данными БСП. Он пытается зарегистрировать изменения справочника на всех существующих узлах планов обмена. Для этого вызывается процедура ЗарегистрироватьОбъектНаВсехУзлах общего модуля СтандартныеПодсистемыСервер.
Внутри этой процедуры выполняется запрос для получения предопределенного элемента плана обмена «Полный»:
Запрос.УстановитьПараметр("ЭтотУзел", ПланыОбмена[ИмяПланаОбмена].ЭтотУзел);
Выясняется аномальное поведение платформы: метод ПланыОбмена[ИмяПланаОбмена].ЭтотУзел вместо корректной ссылки на предопределенный элемент возвращает значение Неопределено. В результате переменная Получатель принимает пустое значение, что и приводит к ошибке несоответствия типов при попытке добавить ее в коллекцию получателей обмена.
При этом стандартное тестирование и исправление (ТИИ) информационной базы со всеми включенными проверками, а также утилита проверки файловых баз chdbfl.exe не находят никаких повреждений ни до, ни после обновления.
Если вам необходимо срочно запустить базу данных и завершить обновление, можно воспользоваться временным исправлением кода в общем модуле. Этот способ позволит пропустить регистрацию поврежденного узла и успешно завершить процесс обновления в пользовательском режиме.
Выполните следующие действия по шагам:
СтандартныеПодсистемыСервер.ЗарегистрироватьОбъектНаВсехУзлах.
Процедура ЗарегистрироватьОбъектНаВсехУзлах(Знач Объект, Знач ИмяПланаОбмена, Знач ВключаяГлавныйУзел = Истина) Экспорт
// Начало вставки временного обхода ошибки
Если ПланыОбмена[ИмяПланаОбмена].ЭтотУзел = Неопределено Тогда
Возврат;
КонецЕсли;
// Конец вставки временного обхода ошибки
// Далее следует типовой код процедуры...
После внесения изменений сохраните конфигурацию и запустите базу в режиме «1С:Предприятие». Обновление завершится без ошибок.
Важное предупреждение: Данный метод является исключительно временным костылем! Он устраняет лишь симптом, но не лечит саму проблему. База данных при этом остается логически поврежденной. После применения такого обхода любая попытка выполнить реструктуризацию таблиц или запустить тестирование и исправление на СУБД (например, MS SQL Server) приведет к аварийному завершению работы с ошибкой дублирования первичных ключей в системных таблицах (PRIMARY KEY constraint violation).
Проанализируем, почему метод ПланыОбмена.ЭтотУзел может возвращать Неопределено. При детальном низкоуровневом анализе работы платформы в момент падения выясняется, что СУБД возвращает внутреннюю ошибку:
Ошибка SDBL: Таблица или поле ID не содержится в разделе FROM.
Это происходит из-за скрытого разрушения внутренней схемы базы данных (таблицы DBSchema). Ошибка формируется еще на исходном релизе. Суть сбоя заключается в том, что в базе данных создаются таблицы разных объектов метаданных с одинаковыми внутренними числовыми идентификаторами (постфиксами). Например, таблица констант Const24 и таблица плана обмена Node24 начинают делить один и тот же системный ID.
Из-за этого конфликта платформа теряет способность корректно определять предопределенные элементы поврежденного плана обмена и возвращает пустые значения. Поскольку стандартные средства ТИИ не анализируют перекрестные ссылки структуры таблиц в DBSchema, они рапортуют об отсутствии ошибок.
Для того чтобы полностью избавиться от скрытого повреждения структуры и гарантировать стабильную работу базы в будущем, необходимо пересоздать схему данных. Самым надежным способом является перенос информации в «чистую» целевую базу.
Выполните этот процесс по шагам:
Загрузка = Истина. Это гарантирует сохранение всех внутренних уникальных идентификаторов (GUID) объектов, что исключит дублирование данных и сохранит ссылочную целостность.Этот метод полностью пересоздаст таблицы базы данных на уровне СУБД, устранит логические конфликты идентификаторов и вернет корректную работоспособность планам обмена.
Иногда сбой получения предопределенного узла вызван более простой ошибкой — физическим раздвоением записи «Этот узел» в таблице плана обмена из-за некорректно настроенной или прерванной синхронизации данных.
Для исправления такой ситуации компания 1С разработала специализированную утилиту, доступную на диске ИТС. Сделайте следующее:
ReplaceWrongThisNodeReferencesAfterTestAndRepair.epf (Замена ссылок на неправильную запись ЭтотУзел).При обновлении конфигураций на платформах ветки 8.3.12 вы можете столкнуться со смежной ошибкой, которая мешает процессу обновления:
ОбщаяКартинка.Обсуждения: Имя не уникально!
Выясним причину этой проблемы: это официально зарегистрированный баг платформы (код ошибки 00-00177655), связанный со встроенной библиотекой стандартных подсистем (БСП). Для обхода этой ошибки выполните одно из двух действий:
Обсуждения и временно переименуйте ее в ПодключениеОбсуждений, после чего повторите процесс обновления.Используя предложенные методики, мы можем не только быстро обойти возникшую проблему для запуска оперативного учета, но и полностью восстановить физическую структуру таблиц базы данных, обеспечив ее надежную эксплуатацию и беспроблемное обновление на любые последующие релизы.