При обновлении нетиповых или даже полностью типовых конфигураций «1С:Предприятие» разработчики и администраторы баз данных иногда сталкиваются с крайне неприятной проблемой. В процессе обновления конфигурации новые справочники или планы счетов успешно добавляются, в Конфигураторе мы отчетливо видим предопределенные элементы, однако при запуске базы в режиме «1С:Предприятие» эти элементы не создаются. Справочники остаются абсолютно пустыми.
Особенно часто такая проблема возникает в крупных прикладных решениях, таких как «Бухгалтерия предприятия 3.0» (БП), «ERP Управление предприятием» или «Комплексная автоматизация». Обычное тестирование и исправление (ТИИ) базы данных далеко не всегда способно решить эту задачу, а стандартные попытки обновления могут завершаться без видимых ошибок, но и без желаемого результата.
В этой статье мы подробно разберем внутренние механизмы платформы «1С:Предприятие 8.3», выясним первопричины сбоя инициализации данных и рассмотрим несколько проверенных практических способов принудительного создания предопределенных элементов.
Для начала давайте проанализируем, как платформа работает с предопределенными данными. Начиная с версии 8.3, логика связи объектов конфигурации с записями в таблицах баз данных претерпела серьезные изменения. Связующим звеном теперь выступает стандартный реквизит ИмяПредопределенныхДанных. При первом обращении или при первом запуске информационной базы после обновления платформа считывает метаданные и автоматически генерирует элементы в физической таблице базы данных, связывая их по имени.
Однако автоматическая генерация происходит только в том случае, если платформа считает, что инициализация конкретного объекта метаданных еще ни разу не проводилась. Если в информационной базе уже проводились какие-либо манипуляции с этим справочником (например, в него программно записывались данные, переносились элементы через правила обмена или база была создана из распределенного узла), внутренний флаг инициализации в таблицах базы данных может быть установлен в значение «Истина».
В таком случае ни стандартный запуск, ни даже принудительное тестирование базы данных не заставят платформу автоматически досоздать новые элементы, так как с ее точки зрения процесс инициализации этого справочника уже успешно завершен. Давайте разберем по шагам, как решить эту проблему с помощью различных инструментов.
Перед тем как приступать к написанию кода, мы должны попробовать стандартный механизм принудительного обновления, заложенный разработчиками платформы «1С:Предприятие».
Для этого нам потребуется запустить информационную базу в режиме «Предприятие» со специальным ключом командной строки. Давайте выполним следующие действия:
/SetPredefinedDataUpdate -UpdateAutomatically
Этот параметр сообщает платформе, что при старте системы необходимо принудительно выставить режим обновления предопределенных данных в значение "Авто" для всех объектов метаданных и попытаться обновить их структуры в базе.
После успешного запуска базы обязательно зайдем в проблемный справочник и проверим результат. Если элементы появились, то закрываем программу, удаляем данный ключ из параметров запуска (чтобы не замедлять последующие входы в систему) и продолжаем работу в штатном режиме. Если же данный метод не принес результата, переходим к более глубоким техническим решениям.
Если стандартный ключ запуска не помог, это означает, что платформа заблокировала автоматическое создание элементов из-за сохраненного статуса инициализации справочника. Начиная с версии платформы 8.3.6, у разработчиков появился доступ к программному управлению этим состоянием.
Мы можем написать небольшую внешнюю обработку (или выполнить код через универсальную консоль кода), которая сбросит внутренний флаг инициализации для конкретного справочника и заставит систему выполнить обновление предопределенных данных принудительно.
Рассмотрим пример кода для справочника НаборыДополнительныхРеквизитовИСведений:
// Шаг 1. Сбрасываем флаг того, что предопределенные данные справочника уже инициализировались в БД
Справочники.НаборыДополнительныхРеквизитовИСведений.УстановитьИнициализациюПредопределенныхДанных(Ложь);
// Шаг 2. Принудительно задаем режим автоматического обновления для этого объекта
Справочники.НаборыДополнительныхРеквизитовИСведений.УстановитьОбновлениеПредопределенныхДанных(ОбновлениеПредопределенныхДанных.Авто);
// Шаг 3. Запускаем глобальную инициализацию предопределенных данных
ИнициализироватьПредопределенныеДанные();
Сообщить("Процедура инициализации успешно выполнена!");
Данный код сбрасывает флаг инициализации в системных таблицах базы данных. При выполнении метода ИнициализироватьПредопределенныеДанные() платформа заново сканирует метаданные справочника в Конфигураторе, сравнивает их с записями в таблице базы данных, находит отсутствующие элементы и создает их.
Если ваша конфигурация построена на базе БСП (а это практически все современные конфигурации от фирмы 1С, включая «Бухгалтерию предприятия 3.0»), мы можем воспользоваться готовыми экспортными процедурами общих модулей. Разработчики БСП предусмотрели подобные сбои и создали готовые механизмы восстановления.
Для запуска этих процедур нам также потребуется консоль разработчика или внешняя обработка в режиме «1С:Предприятие» с правами Администратора.
Вариант А. Глобальное восстановление по всем метаданным базы
Если проблема затронула сразу несколько справочников или планов счетов, мы можем вызвать универсальную процедуру обновления всех предопределенных элементов:
СтандартныеПодсистемыСервер.ВосстановитьПредопределенныеЭлементы();
Этот метод последовательно обойдет все объекты метаданных в системе, выявит расхождения между Конфигуратором и базой данных и автоматически досоздаст недостающие элементы с генерацией новых корректных идентификаторов.
Вариант Б. Обновление конкретного объекта метаданных
Если мы хотим точечно обновить только один конкретный справочник, не затрагивая остальные объекты, воспользуемся другим методом общего назначения БСП:
МетаданныеОбъекта = Метаданные.Справочники.НаборыДополнительныхРеквизитовИСведений;
ОбщегоНазначения.ОбновитьПредопределенныеЭлементы(МетаданныеОбъекта);
Этот способ является наиболее безопасным для баз данных, находящихся в активной эксплуатации, так как работает изолированно и не создает лишней нагрузки на транзакции СУБД.
Довольно часто описанная проблема возникает в базах данных, которые когда-то являлись подчиненными узлами Распределенной Информационной Базы (РИБ), но затем были «отвязаны» от главного узла для перевода в автономный режим.
Дело в том, что в подчиненных узлах РИБ создание любых предопределенных элементов на уровне платформы жестко заблокировано. Система ожидает, что новые предопределенные элементы придут вместе с пакетом миграции данных из главного узла (чтобы избежать задвоения уникальных идентификаторов UUID). Если отвязка от главного узла была выполнена некорректно (например, просто удалили план обмена без очистки главного узла в коде), база продолжает считать себя подчиненным узлом.
Давайте проверим этот статус и окончательно разорвем связь с главным узлом. Для этого выполним следующий код:
Если ПланыОбмена.ГлавныйУзел() <> Неопределено Тогда
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Сообщить("Связь с главным узлом РИБ успешно разорвана.");
Иначе
Сообщить("База не является подчиненным узлом РИБ.");
КонецЕсли;
После выполнения этой команды база полностью переходит в статус главной (автономной), блокировки на создание предопределенных данных снимаются. После этого мы можем повторно применить Способ 2 или Способ 3 для окончательного создания недостающих элементов.
В некоторых исключительных случаях, когда база данных имеет внутренние логические повреждения структуры таблиц, даже программные методы БСП могут возвращать ошибки. В такой ситуации мы можем прибегнуть к "ручному" созданию элемента в режиме Предприятия с последующей жесткой привязкой к имени предопределенного из Конфигуратора.
Давайте разберем, как это сделать по шагам:
// Шаг 1. Находим только что созданный нами элемент
ЭлементОбъект = Справочники.НаборыДополнительныхРеквизитовИСведений.НайтиПоНаименованию("Общие").ПолучитьОбъект();
Если ЭлементОбъект <> Неопределено Тогда
// Шаг 2. Прописываем имя предопределенного элемента точь-в-точь как в Конфигураторе
ЭлементОбъект.ИмяПредопределенныхДанных = "Справочник_НаборыДополнительныхРеквизитовИСведений_Общие";
// Шаг 3. Записываем объект для фиксации изменений
ЭлементОбъект.Записать();
Сообщить("Элемент успешно связан с метаданными конфигуратора!");
КонецЕсли;
Как только мы записываем объект с заполненным свойством ИмяПредопределенныхДанных, платформа автоматически идентифицирует его как предопределенный. Иконка элемента в списках мгновенно поменяется (на ней появится характерная желтая точка), и прикладной код конфигурации начнет корректно обращаться к этому элементу по его имени.
Проблема с обновлением предопределенных данных — это известная особенность работы платформы 1С версии 8.3, которая чаще всего вызвана сбоем флагов инициализации или остаточными признаками подчиненности узлов РИБ. Чтобы минимизировать риски возникновения подобных ошибок при регулярных обновлениях, мы рекомендуем придерживаться следующих правил: