← На главную

При переходе на новые релизы 1С:Управление нашей фирмой (УНФ), особенно при переходе с ветки 1.6.18 на 1.6.19 и выше, технические специалисты часто сталкиваются с критической ошибкой: «Идентификатор объекта стал неуникальным». Эта проблема блокирует процесс реструктуризации базы данных и не позволяет завершить обновление. Ситуация осложняется тем, что стандартные методы, такие как простая выгрузка/загрузка .dt или обычное тестирование и исправление, не всегда приносят результат.

В данной статье мы подробно разберем причины возникновения этой коллизии и рассмотрим пошаговый алгоритм действий для восстановления работоспособности базы данных.

Выясним причину возникновения ошибки

Прежде всего, проанализируем ситуацию. Ошибка возникает на этапе реструктуризации таблиц базы данных. В системе 1С:Предприятие каждый объект метаданных (справочник, документ, реквизит) имеет свой уникальный внутренний идентификатор (UUID). При обновлении конфигурации платформа сопоставляет старые идентификаторы с новыми. Если в системных таблицах (таких как Config, ConfigSave или ConfigCAS) появляются записи с дублирующимися UUID или именами, процесс прерывается.

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

Шаг 1. Полное тестирование и исправление с особыми параметрами

Как показывает практика практикующих программистов, стандартного «Тестирования и исправления» (ТИИ) может быть недостаточно, если не выбраны правильные опции. Разберем алгоритм действий в Конфигураторе:

1. Обязательно создайте резервную копию базы данных (файл 1Cv8.1CD).
2. Зайдите в меню Администрирование — Тестирование и исправление.
3. Установите флажки на пунктах:
   • Реиндексация таблиц информационной базы;
   • Проверка логической целостности;
   • Проверка ссылочной целостности;
   • Пересчет итогов;
   • Сжатие таблиц информационной базы (критично для удаления «мусора»);
   • Реструктуризация таблиц информационной базы.
4. Важный нюанс: Обратите внимание на настройки расширений. Даже если в списке «Конфигурация — Расширения» пусто, платформа могла сохранить кэшированные данные расширений в структуре файла. Выполните тестирование повторно, убедившись, что все объекты конфигурации проходят полную проверку.

Если в процессе ТИИ утилита chdbfl.exe находит ошибки, которые не может исправить, это верный признак логического разрушения структуры таблиц метаданных.

Шаг 2. Работа с расширениями и патчами

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

1. Удалите абсолютно все расширения перед запуском обновления.
2. Зайдите в раздел Администрирование — Обслуживание — Обновление программы — Установленные исправления (патчи) и удалите все имеющиеся записи.
3. После удаления патчей обязательно выполните очистку кэша конфигурации. Это можно сделать, запустив 1С с параметром /ClearConfigCache или вручную очистив папки в %LOCALAPPDATA%\1C\1Cv8\.

Посмотрим на пример того, почему это важно: при обновлении УНФ 1.6.19 происходит серьезное изменение структуры журналов документов. Если патч, предназначенный для версии 1.6.18, пытается «удержать» старую структуру метаданных, возникает конфликт идентификаторов.

Шаг 3. Использование типовой обработки БСП

Поскольку УНФ построена на базе Библиотеки стандартных подсистем (БСП), в ней существует справочник ИдентификаторыОбъектовМетаданных. Если проблема в нем, нам поможет специальный инструмент. Выясним, как с ним работать:

1. Найдите в составе БСП (или в самой конфигурации через «Все функции/Функции для технического специалиста») обработку «Редактирование идентификаторов объектов метаданных».
2. Запустите проверку на наличие дублей.
3. Используйте команду «Обновить из конфигурации». Это заставит систему сопоставить записи в справочнике с реальными объектами метаданных в текущем cf-файле.

Шаг 4. Обновление версии платформы

Проанализируем технические требования релизов УНФ. Версии ветки 1.6.19 крайне чувствительны к версии платформы 1С:Предприятие. На старых релизах платформы (ниже 8.3.15) механизмы реструктуризации могли работать некорректно с длинными идентификаторами таблиц. Рекомендация: перед обновлением конфигурации обновите платформу до актуального стабильного релиза (например, последней версии 8.3.22 или выше).

Шаг 5. Работа с журналами документов (продвинутый метод)

Если ошибка сохраняется, вероятно, проблема в конкретной таблице журнала документов, которая перестраивается при обновлении. Попробуем следующий метод:

1. В Конфигураторе (в копии базы!) попробуйте временно удалить основные журналы документов (предварительно сохранив cf).
2. Попробуйте обновиться без них. Если обновление прошло — значит, проблема была в индексах журналов.
3. Верните журналы, загрузив исходную конфигурацию через сравнение-объединение. Это заставит систему заново создать индексы и таблицы журналов, что может устранить дублирование идентификаторов в системных таблицах.

Шаг 6. Метод «Чистого листа»

Если ошибка «Идентификатор объекта стал неуникальным» не уходит даже после ТИИ, применим метод переноса конфигурации через файлы:

1. Выгрузите конфигурацию из проблемной базы в файлы (Конфигурация — Выгрузить конфигурацию в файлы...).
2. Создайте абсолютно новую пустую базу данных.
3. Загрузите конфигурацию из файлов в новую базу.
4. Выгрузите из новой базы .cf файл.
5. В исходной базе сделайте Конфигурация — Загрузить конфигурацию из файла..., выбрав только что созданный .cf.

Этот метод часто помогает избавиться от «фантомных» записей в таблице Config, так как при выгрузке в файлы и обратной сборке мусорные данные не переносятся.

Заключение

Мы рассмотрели основные способы решения проблемы с неуникальными идентификаторами. В большинстве случаев помогает полное ТИИ со сжатием таблиц и предварительным удалением всех патчей. Помните, что работа с метаданными на уровне файлов — это крайняя мера, и всегда начинайте с проверки целостности базы стандартными средствами платформы.