Переход с файловой версии информационной базы 1С на серверный вариант (MS SQL Server) — процедура стандартная, но часто сопровождающаяся техническими сложностями. Одной из самых неприятных ошибок является сбой при загрузке файла .dt, когда процесс прерывается сообщением: «Попытка вставки неуникального значения в уникальный индекс». В этой статье мы подробно разберем, почему возникает эта проблема, как найти «проблемную» таблицу и какие инструменты использовать для очистки данных, чтобы успешно завершить миграцию.
Для начала проанализируем ситуацию. Файловая база данных (формат .1CD) обладает менее строгими механизмами контроля уникальности данных на физическом уровне по сравнению с промышленными СУБД, такими как MS SQL Server или PostgreSQL. В процессе эксплуатации из-за сбоев оборудования, некорректного завершения работы или программных ошибок в индексах файловой базы могут появиться дублирующиеся записи. Пока база находится в файловом режиме, 1С может «не замечать» эти дубли.
Однако при загрузке данных из .dt в SQL Server происходит следующее: система сначала заливает «сырые» данные в таблицы, а затем начинает создавать индексы, предусмотренные конфигурацией. Как только очередь доходит до создания уникального индекса (Unique Index), SQL Server обнаруживает две или более идентичные строки, которые по правилам метаданных должны быть уникальными. Инструкция CREATE UNIQUE INDEX прерывается, и загрузка всей базы данных останавливается.
В тексте ошибки часто фигурирует имя таблицы, например _InfoRg20068. Это внутреннее имя таблицы в SQL, которое соответствует конкретному объекту метаданных (чаще всего регистру сведений).
Прежде чем что-то исправлять, нам нужно понять, какой именно регистр содержит дубли. В системе 1С:Предприятие имена таблиц в СУБД не совпадают с именами в конфигураторе. Проанализируем способы получения реального имени объекта:
_InfoRg20068), мы можем сопоставить его, понимая, что InfoRg — это Information Register (Регистр сведений).Первым делом попробуем стандартные средства платформы. Откроем файловую базу в режиме Конфигуратор и перейдем в меню Администрирование — Тестирование и исправление. Проанализируем настройки, которые необходимо выставить:
Важно помнить, что стандартное ТиИ не всегда находит дубли в измерениях регистров сведений, если логика их уникальности нарушена на уровне записей. Если после ТиИ выгрузка и загрузка снова выдают ошибку, перейдем к более глубоким методам.
Если проблема кроется в физическом повреждении файла .1CD, воспользуемся утилитой chdbfl.exe, которая находится в папке bin установленной платформы 1С. Рассмотрим порядок действий:
Эта утилита проверяет физическую структуру таблиц и может удалить поврежденные страницы данных, которые создают фантомные дубли.
Как показывает практика, в конфигурации «Комплексная автоматизация 1.1» виновниками чаще всего становятся регистры ключей аналитики. Это связано с работой механизма РАУЗ (Расширенная аналитика учета затрат). Рассмотрим решение, которое помогло автору вопроса:
В этих конфигурациях предусмотрена специализированная обработка. Чтобы ее найти, нужно переключиться в интерфейс «Заведующий учетом» или найти через меню «Операции — Обработки — Тестирование и очистка ключей аналитики».
Разберем, почему это эффективно:
Важно: Данная процедура на больших базах может занимать несколько часов (как в примере автора — около 2 часов), но это самый надежный способ «вылечить» аналитические регистры.
Если мы точно определили имя регистра (например, РегистрСведений.АналитикаУчетаНоменклатуры), мы можем найти дублирующие записи с помощью запроса прямо в режиме «1С:Предприятие». Посмотрим на пример логики такого запроса:
ВЫБРАТЬ
Измерение1,
Измерение2,
Измерение3,
КОЛИЧЕСТВО(*) КАК КоличествоДублей
ИЗ
РегистрСведений.НазваниеВашегоРегистра
СГРУППИРОВАТЬ ПО
Измерение1,
Измерение2,
Измерение3
ИМЕЮЩИЕ
КОЛИЧЕСТВО(*) > 1
После того как дубли найдены, их необходимо удалить. Сделать это можно программно, используя набор записей с установленным отбором по найденным измерениям. Мы оставляем одну корректную запись, а остальные удаляем. Рассмотрим пример кода для удаления:
НаборЗаписей = РегистрыСведений.НазваниеВашегоРегистра.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.Измерение1.Установить(Значение1);
НаборЗаписей.Отбор.Измерение2.Установить(Значение2);
// Устанавливаем все измерения, составляющие уникальный ключ
НаборЗаписей.Прочитать();
Если НаборЗаписей.Количество() > 1 Тогда
Пока НаборЗаписей.Количество() > 1 Цикл
НаборЗаписей.Удалить(0); // Удаляем лишние, оставляя одну
КонецЦикла;
НаборЗаписей.Записать();
КонецЕсли;
Иногда ошибка возникает не из-за фактических дублей, а из-за различий в параметрах сравнения строк (Collation). Например, в файловой базе строки "Объект" и "ОБЪЕКТ" считаются разными, а в SQL Server с настройкой Case-Insensitive (нечувствительность к регистру) они станут идентичными, что вызовет конфликт уникального индекса.
Также обратим внимание на «Смещение дат». При создании базы в SQL Server для 1С рекомендуется устанавливать смещение 2000. Если в файловой базе есть даты ранее 1753 года (нижний порог SQL Server), это может привести к непредсказуемым ошибкам при генерации индексов таблиц, содержащих даты в качестве измерений.
Для успешного решения проблемы придерживаемся следующего алгоритма:
chdbfl.exe для исключения физических повреждений.После выполнения этих шагов выгружаем новый .dt и пробуем загрузить его в пустую базу SQL. Как правило, после очистки аналитических регистров загрузка проходит без ошибок.