При переводе информационной базы 1С из файлового режима (файла 1cv8.1cd) в клиент-серверный вариант через выгрузку и загрузку файла выгрузки .dt системные администраторы и разработчики часто сталкиваются со следующей ошибкой:
«Ошибка загрузки информационной базы. В информационную базу загружены не все данные по причине: Попытка вставки неуникального значения в уникальный индекс: Microsoft SQL Server Native Client... Выполнение инструкции CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта...»
Рассмотрим, почему возникает эта проблема, как определять поврежденные таблицы и какими проверенными способами можно успешно загрузить базу данных в MS SQL Server или PostgreSQL.
Файловый движок 1С более «снисходителен» к нарушениям уникальности и целостности данных, чем промышленная СУБД. В файловой базе могут годами хранить записи с одинаковыми нулевыми идентификаторами GUID, испорченными датами (например, 5999 год) или рассинхронизированными таблицами итогов. При выгрузке в файл .dt эти данные сохраняются «как есть».
Однако при загрузке выгрузки в SQL сервер платформа 1С формирует физические таблицы и строит для них уникальные индексы с помощью команды CREATE UNIQUE INDEX. Когда SQL Server обнаруживает две одинаковые строки в поле, по которому создается уникальный индекс, транзакция загрузки откатывается, и весь процесс завершается ошибкой.
Разберем основные причины появления дубликатов:
_AccRgChngR..., _DocumentChngR... хранят узлы обмена. Если в них накапливаются битые записи, индекс ByNodeMsg_RNR падает при загрузке.Params или справочнике пользователей (индексы по users.usr или таблице Files) содержат неверные служебные даты модификации._AccumRgT..., _AccRgAT...) содержат некорректные или задублированные записи.0x00000000....В тексте ошибки СУБД всегда указывается имя таблицы SQL, например: dbo._InfoRg5983 или dbo._AccRgChngR1622. Чтобы понять, какой объект конфигурации 1С вызывает сбой, выполним в файловой базе следующий код в обработке или внешнем отчете:
СтруктураБазы = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого ТаблицаИзСтруктуры Из СтруктураБазы Цикл
Если ТаблицаИзСтруктуры.ИмяТаблицыХранения = "_InfoRg5983" Тогда
Сообщить("Имя объекта метаданных: " + ТаблицаИзСтруктуры.ИмяМетаданных);
Сообщить("Назначение таблицы: " + ТаблицаИзСтруктуры.Назначение);
КонецЕсли;
КонецЦикла;
Выяснив назначение таблицы, переходим к выработке подходящего решения.
Самый простой и стандартный способ — исправление физической и логической целостности базы в Конфигураторе файловой базы 1С.
Проанализируем порядок действий:
Платформа автоматически найдет не уникальные записи в регистрах сведений и сбросит некорректные итоги. После завершения ТИИ повторно выгружаем базу в файл .dt и загружаем на SQL-сервер.
Если имя таблицы содержит ключевые слова ChngR (например, _DocumentChngR7258 или _AccRgChngR1622) и индексы вида _ByNodeMsg_RNR, значит, ошибка кроется в поврежденной таблице регистрации изменений для обмена данными.
Если узлы обмена в данный момент не критичны или могут быть зарегистрированы заново, решим проблему полной очисткой регистрации изменений:
Все функции / Функции для специалиста > Обработки > Регистрация изменений для обмена данными)..dt и загружаем его в SQL.Если SQL падает на уникальном индексе таблицы dbo.Params с ключом вида users.usr или на таблице Files, причина заключается в некорректных датах модификации пользователей, содержащихся в служебной таблице параметров.
Чтобы заставить 1С перезаписать служебные записи правильной датой, выполним следующую процедуру:
При сохранении карточки платформа генерирует новую корректную дату модификации записи в таблице Params. После этой операции выгрузка загрузится в SQL без ошибок.
Файл .dt не является средствами резервного копирования и иногда «сбоит» при смене архитектуры хранения. Если загрузка .dt продолжает блокироваться индексом, применим прямой перенос данных через универсальный формат XML, обходя механизмы выгрузки .dt:
.cf (меню Конфигурация > Сохранить конфигурацию в файл)..cf. При создании базы на SQL рекомендуем указывать параметр «Смещение дат = 2000».ВыгрузкаЗагрузкаДанныхXML.epf.Если проблема возникает в таблице итогов регистра накопления или бухгалтерии, можно программно отключить использование итогов для проблемного регистра перед выгрузкой в .dt:
// Отключаем итоги регистра перед выгрузкой dt
РегистрыНакопления.РасчетыПоЭквайрингу.УстановитьИспользованиеИтогов(Ложь);
После отключения итогов выгружаем базу в .dt, загружаем ее в MS SQL, а затем включаем итоги заново и выполняем их пересчет:
// Включаем итоги и пересчитываем их в SQL базе
РегистрыНакопления.РасчетыПоЭквайрингу.УстановитьИспользованиеИтогов(Истина);
РегистрыНакопления.РасчетыПоЭквайрингу.ПересчитатьИтоги();
Проанализировав рассмотренные варианты, можно сделать вывод: в 90% случаев комбинация полного ТИИ с пересчетом итогов и очистки таблиц регистрации изменений позволяет полностью устранить неуникальность ключей и успешно перевести информационную базу 1С на сервер SQL.