При обновлении нетиповых конфигураций или попытке «вернуть базу к типовой» многие специалисты сталкиваются с досадной ошибкой: «Запись с такими ключевыми полями существует! РегистрСведений.ИмяРегистра». Ситуация осложняется тем, что при проверке в режиме «Предприятие» или через консоль запросов никаких дублей не обнаруживается. Разберем подробно, почему возникает этот «фантомный» конфликт и как правильно провести реструктуризацию данных, чтобы завершить обновление.
Проанализируем механику работы платформы 1С. Основная причина, по которой возникают ошибки уникальности при обновлении, заключается не в наличии реальных дублей в текущей базе, а в способе внесения изменений в конфигурацию. Рассмотрим ситуацию, когда вместо постепенного обновления через .cfu файлы или сравнение-объединение используется команда «Загрузить конфигурацию из файла» (Load CF).
Внутри системы 1С каждый объект (справочник, документ, измерение регистра) идентифицируется не по имени, а по внутреннему уникальному идентификатору — GUID. Если в базе-источнике (откуда выгружен CF) и в вашей рабочей базе идентификаторы измерений регистра различаются (даже если их имена абсолютно одинаковы), платформа при загрузке конфигурации воспримет это следующим образом:
Во время процесса реструктуризации данных система пытается перенести информацию. Но так как «новое» измерение для базы является абсолютно незнакомым, оно заполняется значениями по умолчанию (пустыми ссылками, нулевыми датами или числами). Если в регистре было несколько записей, которые раньше различались только по этому измерению, то после его «обнуления» они становятся идентичными в глазах СУБД. Именно в этот момент возникает нарушение уникальности индекса.
Прежде чем приступать к радикальным мерам, проверим наличие дублей корректным запросом. Ошибка в Сообщении 3 на форуме заключалась в том, что в группировку были включены ресурсы регистра. Помните: уникальность регистра сведений определяется только его измерениями (и периодом, если регистр периодический). Ресурсы и реквизиты на уникальность не влияют.
Рассмотрим пример правильного запроса для поиска дублей в независимом непериодическом регистре ИсторияЭСФ. Нам нужно сгруппировать данные только по ключевым полям и найти те комбинации, которые встречаются более одного раза:
ВЫБРАТЬ
ИсторияЭСФ.ЭСФ КАК ЭСФ,
ИсторияЭСФ.НомерЗаписи КАК НомерЗаписи,
КОЛИЧЕСТВО(*) КАК КоличествоДублей
ИЗ
РегистрСведений.ИсторияЭСФ КАК ИсторияЭСФ
СГРУППИРОВАТЬ ПО
ИсторияЭСФ.ЭСФ,
ИсторияЭСФ.НомерЗаписи
ИМЕЮЩИЕ
КОЛИЧЕСТВО(*) > 1
Если этот запрос ничего не вернул, значит, проблема стопроцентно кроется в изменении структуры (реструктуризации), и ваши записи становятся одинаковыми только в процессе обновления из-за очистки полей.
Посмотрим на ситуацию, описанную автором: база «Бухгалтерия для Казахстана» обновлялась некорректно, и GUID объектов разошлись с типовой конфигурацией поставщика. Загрузка «чистого» CF-файла в этом случае — верный путь к потере данных или ошибкам уникальности. Разберем, как исправить это правильно.
Вместо «Загрузить конфигурацию из файла», используем алгоритм сравнения и объединения:
Если реструктуризация уже запущена, а количество регистров с ошибками растет (как в Сообщении 29), проанализируем возможность временной очистки данных. Этот метод допустим только в том случае, если данные в регистре являются восстановимыми (например, записи логов, статусов обмена или истории, которую можно перепровести).
Рассмотрим пошагово алгоритм «Очистка — Обновление — Загрузка»:
Набор = РегистрыСведений.ИсторияЭСФ.СоздатьНаборЗаписей();
Набор.Записать();
В контексте конфигурации «Бухгалтерия для Казахстана» (БК), регистр ИсторияЭСФ хранит критически важные сведения о взаимодействии с государственным порталом. Проанализируем последствия удаления записей в нем: если их просто стереть, документы ЭСФ в базе могут потерять связь со своими статусами на сервере («Принят», «Доставлен» и т.д.).
Выясним, как минимизировать риски: если вы все же решили очистить регистр для прохождения обновления, после загрузки данных обязательно проверьте соответствие статусов. В крайнем случае, в БК предусмотрена типовая возможность синхронизации статусов с порталом ИС ЭСФ, которая может восстановить часть истории обмена автоматически.
Ошибка уникальности при обновлении — это почти всегда сигнал о том, что разрушена связь между объектами базы и конфигурацией поставщика. Мы настоятельно рекомендуем избегать команды «Загрузить конфигурацию» для баз с данными, если вы не уверены на 100% в идентичности GUID. Всегда отдавайте предпочтение «Сравнению и объединению» с тщательным визуальным контролем сопоставления измерений и реквизитов.