← На главную

Переход с файлового варианта базы данных на клиент-серверный вариант (MS SQL Server) — это ответственный процесс, который часто выявляет скрытые логические повреждения данных. Одной из самых неприятных ошибок является сообщение о нарушении уникальности индекса (ошибка 23505 или 80040E2F). Разберем по шагам, почему это происходит и как мы можем исправить ситуацию.

Понимание природы ошибки

Когда вы видите сообщение вида The CREATE UNIQUE INDEX statement terminated because a duplicate key was found, это означает, что SQL-сервер при попытке создания индекса обнаружил в данных две или более строки, которые имеют одинаковые ключевые значения. В файловой базе 1CD такие дубли могли существовать «незаметно» для платформы, но при строгом контроле уникальности в MS SQL процесс загрузки прерывается.

Шаг 1: Первичная диагностика и тестирование

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

1. Запустите Тестирование и исправление (ТиИ) в Конфигураторе. Включите проверки: пересчет итогов, реструктуризацию таблиц и проверку логической целостности.
2. Используйте утилиту chdbfl.exe (находится в папке bin установленной платформы). Обязательно установите флаг Исправлять обнаруженные ошибки. Это самый мощный инструмент для борьбы с повреждениями внутри файла .1CD.
3. После выполнения процедур попробуйте снова создать выгрузку .dt и выполнить загрузку.

Шаг 2: Поиск «скрытых» дублей

Если штатные инструменты не помогли, значит, проблема глубже. Часто ошибка возникает в системных таблицах, таких как _AccumRgOpt (настройки хранения итогов регистра). Попробуйте проанализировать структуру базы данных:

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

Шаг 3: Радикальные методы исправления конфигурации

Если данные в таблице регистра накопления критически повреждены, можно попробовать изменить структуру базы «на лету»:

1. Сохраните конфигурацию в файл (cf).
2. Снимите конфигурацию с поддержки.
3. Найдите проблемный регистр накопления, вызвавший ошибку, и временно измените его структуру (например, добавив или удалив незначащий реквизит).
4. Сохраните конфигурацию и выполните реструктуризацию. Это может принудительно «пересобрать» проблемные индексы.
5. Выгрузите базу в .dt и попробуйте загрузить в MS SQL.
6. После успешной загрузки верните конфигурацию из файла обратно на поддержку.

Шаг 4: Использование альтернативных методов переноса данных

Если классический метод через .dt продолжает выдавать ошибку, стоит рассмотреть переход на использование XML-выгрузки. Использование обработки ВыгрузкаЗагрузкаДанныхЧерезXML.epf (доступной на ИТС) позволяет перенести все объекты данных в новую чистую базу SQL, минуя перенос структуры индексов старой файловой базы. В этом случае сервер сам корректно построит все индексы с нуля.

Заключение и рекомендации

Помните, что при работе с поврежденными данными всегда нужно делать резервную копию файла .1CD перед любыми действиями. Если проблема сохраняется, мы советуем проанализировать логи SQL Server Error Log в момент ошибки — там часто указывается более точная информация о том, какой запрос привел к нарушению уникальности, что позволит сузить область поиска до конкретной таблицы базы данных.