Как исправить ошибку переноса базы 1С в SQL из-за некорректных данных в таблице истории версий?

← На главную

Переход с файлового варианта информационной базы на клиент-серверный (SQL) часто сопровождается неожиданными ошибками. Одной из самых частых причин является несоответствие структуры служебных таблиц, в частности _DATAHISTORYVERSIONS, требованиям строгой типизации данных в SQL Server. Давайте разберем, почему возникает ошибка с полем _NODE_TYPE и как поэтапно решить эту проблему.

Причина возникновения ошибки

В файловой версии платформы 1С структура таблиц может содержать записи с нулевыми значениями null там, где SQL Server ожидает строго определенные данные. Когда мы пытаемся загрузить такую базу в SQL, система выполняет проверку ограничений (Constraints). Если в поле _NODE_TYPE обнаруживаются записи null, а структура требует NOT NULL, процесс переноса прерывается с ошибкой.

Способ 1: Временное понижение режима совместимости

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

Откройте конфигуратор вашей текущей файловой базы.
Зайдите в свойства конфигурации (верхний узел дерева метаданных).
Найдите свойство Режим совместимости.
Установите значение Версия 8.3.10 (или ниже, если это допустимо для вашей конфигурации).
Сохраните изменения и выполните полное обновление конфигурации базы данных.
Попробуйте выполнить выгрузку в .dt файл и загрузку в SQL-базу.
После успешного переноса верните режим совместимости в исходное состояние.

Важно: Будьте осторожны, если в вашей конфигурации используются специфические методы 8.3.19+, они могут перестать работать при понижении версии. Проверьте работоспособность критически важных подсистем после возврата совместимости.

Способ 2: Использование SQL-триггера для обхода ограничений

Если понижение совместимости не подходит, можно использовать возможности самого SQL Server для динамического изменения структуры таблицы в момент её создания. Мы можем создать триггер на уровне базы данных (DDL-триггер), который будет реагировать на создание таблицы _DATAHISTORYVERSIONS и менять тип поля.

Рассмотрим, как это реализовать:


CREATE TRIGGER trigg_table_create ON DATABASE 
FOR CREATE_TABLE 
AS 
IF EVENTDATA().value('(/EVENT_INSTANCE[1]/ObjectName[1])', 'nvarchar(150)') = '_DATAHISTORYVERSIONS'
    EXEC ('ALTER TABLE _DATAHISTORYVERSIONS ALTER COLUMN _NODE_TYPE INT NULL');

Этот скрипт нужно выполнить в SQL Management Studio в контексте новой базы данных, куда планируется загрузка. При попытке 1С создать таблицу _DATAHISTORYVERSIONS в процессе загрузки, сработает наш триггер и разрешит хранение null значений в поле _NODE_TYPE, что позволит успешно завершить процедуру.

Способ 3: Очистка таблицы через МенеджерИсторииДанных

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

Рассмотрим пример кода, который можно запустить в консоли кода:


МассивМетаданных = Новый Массив;
// Добавьте сюда ссылки на нужные объекты метаданных
// Например: МассивМетаданных.Добавить(Метаданные.Справочники.Номенклатура);

Для Каждого ОбъектМетаданных Из МассивМетаданных Цикл
    МенеджерИсторииДанных.УдалитьВерсии(ОбъектМетаданных);
КонецЦикла;

После выполнения такой очистки рекомендуется повторно запустить Тестирование и исправление в конфигураторе с установленными галочками Реструктуризация таблиц и Сжатие таблиц. Это поможет физически уменьшить размер файла базы данных и удалить «хвосты» от удаленных версий.

Что делать, если ничего не помогает?

Если проблема сохраняется, возможно, дело не только в таблице версионирования. Разберем план действий:

Проверьте наличие логических ошибок в базе с помощью утилиты chdbfl.exe (входит в комплект поставки платформы).
Если база нетиповая, попробуйте выгрузить данные через Выгрузку и загрузку данных в формате XML. Этот метод переносит данные на уровне объектов, что автоматически исключает перенос поврежденных записей из системных таблиц.
Убедитесь, что у пользователя SQL, от имени которого работает 1С, есть полные права на изменение структуры таблиц (DDL-операции).

Работая над этой задачей, помните, что каждое вмешательство в SQL-структуру — это риск. Всегда делайте резервную копию до выполнения команд ALTER TABLE или создания триггеров. Успешного вам переноса базы!