При сопровождении и обновлении нетиповых (измененных) конфигураций 1С специалисты часто сталкиваются со следующей проблемой: в процессе обновления базы данных (клавиша F7 в Конфигураторе) система аварийно завершает работу, выдавая ошибку «Дублирование имени объекта метаданных». Чаще всего эта коллизия затрагивает общие модули (например, РаботаСНоменклатуройКлиент), роли, подписки на события или общие картинки. Для предотвращения таких конфликтов при обновлении нетиповых баз можно использовать способ выноса доработок в расширение для возврата к типовой конфигурации.
В этой статье мы подробно проанализируем, почему платформа 1С «раздваивает» один и тот же объект, выясним глубинные технические причины этого сбоя и рассмотрим пошаговые практические методы его устранения.
Для платформы 1С:Предприятие текстовое имя объекта метаданных (например, общего модуля) вторично. Первичным и главным идентификатором любого объекта в структуре конфигурации является его внутренний уникальный номер — GUID (Globally Unique Identifier). Он присваивается объекту в момент его создания и остается неизменным на протяжении всей «жизни» конфигурации.
Когда мы выполняем процедуру сравнения и объединения конфигураций (или стандартное обновление через файл .cf / .cfu), платформа пытается сопоставить объекты основной конфигурации и конфигурации обновления по следующему алгоритму:
GUID.GUID объект не найден, система пытается сопоставить его по имени (идентификатору метаданных).Давайте посмотрим на схематичный пример того, как видит эту ситуацию XML-структура метаданных 1С:
<!-- Объект в вашей основной конфигурации -->
<CommonModule name="РаботаСНоменклатуройКлиент">
<uuid>11111111-2222-3333-4444-555555555555</uuid>
</CommonModule>
<!-- Тот же самый объект в файле обновления поставщика -->
<CommonModule name="РаботаСНоменклатуройКлиент">
<uuid>aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee</uuid>
</CommonModule>
Поскольку значения в теге uuid (они же GUID) различаются, 1С делает ложный вывод: модуль в вашей рабочей базе — это ваш собственный уникальный объект (разработчика), а модуль из обновления — это абсолютно новый объект поставщика. Система пытается добавить новый модуль, сохранив старый. На этапе записи конфигурации БД происходит коллизия: в одной ветке метаданных не могут находиться два объекта с одинаковыми именами. Конфигуратор блокирует обновление базы данных и возвращает ошибку.
Выясним, из-за чего может произойти такое расхождение в идентичных на первый взгляд базах:
GUID..cf) вместо последовательного обновления (через сравнение-объединение или поддержку), из-за чего затирается история поддержки.Самый правильный и безопасный путь — это восстановить связь между «раздвоившимися» объектами прямо в процессе сравнения-объединения. Для этого выполним следующие шаги:
РаботаСНоменклатуройКлиент и модуль поставщика будут находиться на разных строках. Один будет помечен как «отсутствует в новой конфигурации», а другой — как «отсутствует в основной конфигурации».После этой несложной операции строки объединятся в одну. Платформа поймет, что это один и тот же объект, перезапишет старый GUID корректным идентификатором от поставщика, и ошибка дублирования исчезнет.
Иногда дублирование происходит из-за того, что в новой версии поставщика объект был упразднен (или перенесен), а в вашей базе он остался «сиротой» на поддержке. Если таких объектов много, сопоставлять их вручную нецелесообразно. Рассмотрим, как решить эту проблему через параметры обновления:
Важное предупреждение: перед включением этого флага внимательно просмотрите список удаляемых объектов в дереве сравнения. Убедитесь, что система не собирается удалить ваши собственные доработки, которые вы случайно оставили без поддержки. Для удобной детальной проверки расхождений пригодится обработка для анализа отчета о сравнении конфигураций.
Если автоматическое или ручное сопоставление не решает проблему (например, один из модулей «завис» в базе данных и выдает ошибку при любой попытке обновления), необходимо прибегнуть к радикальному, но эффективному методу ручной очистки:
РаботаСНоменклатуройКлиент.Иногда дублирование имен объектов метаданных является следствием внутренних логических ошибок в структуре самой базы данных (например, битые ссылки в таблицах метаданных СУБД). Проанализируем, как локализовать эту проблему с помощью встроенных инструментов диагностики 1С:
Этот внутренний тест платформы детально просканирует всю структуру метаданных, выявит скрытые конфликты связей (например, неработающие подписки на события или дубли в ролях пользователей) и автоматически исправит поврежденные GUID-идентификаторы конфигурации. Для планового обслуживания систем также применяется автоматическое архивирование, обновление и тестирование нескольких баз 1С.
Мы подробно разобрали все грани проблемы с дублированием метаданных при обновлении нетиповых баз 1С. Чтобы минимизировать риски возникновения подобных ошибок в вашей практике в будущем, мы рекомендуем придерживаться нескольких простых правил:
Конфигурация -> Проверка конфигурации)..dt или средствами СУБД) перед выполнением любых операций сравнения и обновления метаданных.