При интенсивной разработке или некорректном объединении конфигураций программисты 1С часто сталкиваются с ситуацией, когда один и тот же объект метаданных (например, ПланВидовХарактеристик.ДополнительныеРеквизитыИСведения) «задваивается». Визуально в дереве метаданных мы видим два объекта с одинаковым именем, но система воспринимает их как абсолютно разные сущности. Проблема кроется в различии внутренних идентификаторов — UUID (Internal ID). Если UUID объекта в вашей базе не совпадает с UUID в конфигурации поставщика, при каждом обновлении 1С будет пытаться создать новый объект, игнорируя существующий.
В этой статье мы подробно разберем, почему это происходит, как правильно изменить UUID объекта метаданных и, самое главное, как при этом не потерять накопленные в базе данные.
Для платформы «1С:Предприятие 8» имя объекта (например, ДополнительныеРеквизитыИСведения) является лишь «дружественным» псевдонимом для разработчика. На уровне базы данных и структуры конфигурации основным связующим звеном является уникальный идентификатор (UUID). Рассмотрим ситуацию: вы создали объект вручную в своей конфигурации, а позже решили внедрить аналогичный блок из типового решения. Несмотря на идентичность имен, их UUID будут разными. При сравнении и объединении система увидит их как два разных объекта. Если не выполнить ручное сопоставление, в вашей конфигурации появится дубль.
Проблема усугубляется тем, что все данные в информационной базе (записи в таблицах, ссылки в документах) «привязаны» к конкретному UUID. Просто удалив один объект и оставив другой, вы рискуете получить «битые ссылки» или пустые значения в реквизитах.
Проанализируем самый простой и безопасный метод, который следует применять еще на этапе обновления. Если вы заметили, что в окне сравнения конфигураций объект (например, наш ПВХ) отображается дважды — один раз в основной конфигурации и один раз в файле обновления — не спешите нажимать кнопку «Выполнить».
После этой операции платформа поймет, что это один и тот же объект, и «накатит» изменения из файла обновления на ваш существующий объект, сохранив его UUID. Однако, если объект уже задвоился и база данных «живет» с неправильным идентификатором, этот способ поможет лишь обновить структуру, но не решит проблему поддержки в будущем. Рассмотрим более радикальные методы.
Если нам необходимо жестко задать конкретный UUID объекту метаданных, мы можем воспользоваться механизмом выгрузки конфигурации в XML-файлы. Выясним причину, по которой обычная замена текста в XML часто не срабатывает. При выгрузке ПланВидовХарактеристик платформа создает отдельный файл с его описанием, где указан идентификатор.
Разберем алгоритм действий по шагам:
ChartsOfCharacteristicTypes/ИмяОбъекта.xml.
<Uuid>596c039c-5764-4448-9366-3d233c467a90</Uuid>
ConfigDumpInfo.xml. Вам необходимо найти упоминание старого UUID и там, заменив его на новый.Рассмотрим, что произойдет после загрузки таких файлов обратно. Платформа обнаружит «новый» (с ее точки зрения) объект и создаст для него новую физическую таблицу в СУБД. Ваши старые данные останутся в старой таблице, которая теперь не связана ни с одним объектом метаданных. В интерфейсе вы увидите пустой список. Чтобы вернуть данные, потребуется дополнительный шаг.
Как мы выяснили, изменение UUID метаданных неизбежно ведет к потере связи с физическими таблицами. Чтобы этого избежать, воспользуемся проверенным методом выгрузки и загрузки данных. Проанализируем последовательность действий:
ЗначенияДополнительныхРеквизитов) и регистры сведений.Почему это работает? Обработка при загрузке сопоставляет объекты по внутренним ссылкам. Если мы подменим идентификаторы в самом файле выгрузки, 1С «положит» данные уже в новые таблицы, соответствующие правильному UUID метаданных.
Рассмотрим ситуацию глубже. В 1С значения дополнительных реквизитов часто хранятся в составных типах данных (например, в регистре сведений ДополнительныеСведения). На уровне SQL-сервера составной тип хранится в нескольких колонках, одна из которых содержит ID типа. Этот ID типа напрямую зависит от внутреннего UUID объекта метаданных.
Если вы просто поменяете UUID объекта, но не обновите данные в регистре, система перестанет «видеть» значения. Для SQL-сервера это будет выглядеть так, будто в ячейке указан идентификатор типа, которого больше не существует в системе. Поэтому после любых манипуляций с UUID метаданных крайне рекомендуется запустить «Тестирование и исправление» с установленными галочками «Реструктуризация таблиц информационной базы» и «Проверка ссылочной целостности».
Современным и более удобным способом решения подобных проблем является использование EDT. В отличие от классического Конфигуратора, EDT изначально работает с проектом как с набором файлов. В этой среде гораздо проще выполнить глобальный поиск по всему проекту по строке UUID и заменить его во всех вхождениях, включая служебные файлы и карты соответствий. Это минимизирует риск того, что вы пропустите упоминание старого идентификатора в каком-нибудь скрытом файле структуры проекта.
Подведем итог нашему исследованию. Исправление задвоения объектов через изменение UUID — задача трудоемкая, требующая понимания внутренней кухни платформы.
Рассмотрим краткий чек-лист для выполнения этой операции:
Следуя этим шагам, мы сможем привести конфигурацию к эталонному виду, сохранив при этом всю историю данных и обеспечив беспроблемное обновление системы в будущем.