Как исправить ошибку и зависание при переносе базы 1С 7.7 из формата DBF в MS SQL Server?

← На главную

Перевод рабочей базы 1С:Предприятия 7.7 из файлового формата DBF в формат клиент-серверной базы MS SQL Server — стандартная административная задача, которая нередко сопровождается труднодиагностируемыми ошибками. Типичный сценарий: штатная процедура выгрузки из конфигуратора проходит успешно, однако на этапе «Загрузить данные» в SQL-базу процесс намертво зависает или аварийно закрывается на обработке определенного вида документов (например, «Оказание услуг»). Рассмотрим причины подобного поведения платформы и разберем по шагам, как выявить источник проблемы и успешно завершить миграцию.

Выясним причину сбоя: различия в хранении данных между DBF и MS SQL

В файловой версии формата DBF требования к целостности и типам данных менее строгие, чем в реляционной СУБД MS SQL Server. В процессе загрузки данных парсер конфигуратора выполняет вставку строк в таблицы SQL, где накладываются жесткие ограничения. Выделим основные факторы, приводящие к прерыванию процесса:

Недопустимые значения дат. В таблицах DBF дата хранится в строковом представлении и может принимать некорректные значения из-за случайных опечаток пользователей (например, 01.01.0201 или нулевые даты). Тип DATETIME в MS SQL Server строго ограничен диапазоном от 1 января 1753 года до 31 декабря 9999 года. Попытка вставить дату вне этого диапазона приводит к ошибке СУБД и мгновенному падению конфигуратора.
Скрытые и недопустимые символы в строках. В текстовых реквизитах документов (особенно неограниченной длины и в поле «Комментарий») могут присутствовать нулевые байты (0x00) или символы конца файла (0x1A), возникающие при аппаратных сбоях сети. При чтении текстового файла выгрузки парсер платформы спотыкается о такие символы и аварийно завершает работу.
Повреждение уникальности и мусор в идентификаторах. В таблицах шапки (1SJOURN) или табличных частях могут появиться дубликаты записей по ключевым полям IDDOC или связке IDDOC + LINENO_. Если в DBF это могло оставаться незамеченным, то в MS SQL наличие уникального кластерного индекса блокирует вставку дубликата.
Ошибки порядка реквизитов в метаданных. Платформа 1С 7.7 критично относится к порядку общих реквизитов: реквизиты с типом «Строка неограниченной длины» в дереве метаданных должны располагаться строго в конце списка.
Переполнение журнала транзакций СУБД. Массовая вставка строк в пустую базу данных генерирует колоссальный объем транзакций. Если целевая база SQL находится в режиме восстановления Full, журнал транзакций стремительно разрастается и блокирует загрузку при нехватке дискового пространства.

Шаг 1. Локализация проблемного объекта с помощью трассировки SQL

Чтобы не гадать, на каком именно объекте происходит сбой, проанализируем выполняемые запросы через инструмент SQL Server Profiler. Для этого выполним следующие действия:

Запустим приложение SQL Server Profiler и создадим новую трассировку для целевого сервера MS SQL.
В фильтрах событий выберем отслеживание RPC:Completed, SQL:BatchStarting и Exception, настроив фильтрацию по имени нашей базы данных.
Запустим в конфигураторе 1С 7.7 команду «Администрирование» — «Загрузить данные».
В момент остановки или падения конфигуратора проанализируем последние выполненные SQL-инструкции в окне профайлера. Это позволит точно определить имя таблицы (например, DHXXXX — шапка документа, или DTXXXX — табличная часть), номер строки и идентификатор документа IDDOC, на котором произошел сбой.

Шаг 2. Проверка и очистка данных в исходной базе DBF

После того как проблемный вид документа определен (например, «Оказание услуг»), перейдем к исправлению исходных файлов. Разберем практические шаги по устранению дефектов в исходной копии DBF перед повторной выгрузкой:

Тестирование и исправление (ТИИ). Откроем копию исходной DBF-базы в конфигураторе, перейдем в меню «Администрирование» — «Тестирование и исправление ИБ». Обязательно включим флажки «Проверка физической целостности», «Реиндексация» и «Проверка логической целостности». Это исправит нарушенные внутренние индексы.
Проверка дат в журнале документов. С помощью внешних обработок или прямого чтения таблицы 1SJOURN.DBF проверим поле DATE_TIME_IDDOC на наличие пустых дат или дат ранее 17530101. При обнаружении некорректных дат исправим их на актуальные значения.

Анализ текстовых полей и комментариев. Напишем обработку для поиска и очистки непечатных управляющих символов в реквизитах документов проблемного типа:


Док = СоздатьОбъект("Документ.ОказаниеУслуг");
Док.ВыбратьДокументы();
Пока Док.ПолучитьДокумент() = 1 Цикл
    Если ПустаяСтрока(Док.Комментарий) = 0 Тогда
        Стр = Док.Комментарий;
        // Удаляем недопустимые нулевые символы
        СтрОчищенная = СтрЗаменить(Стр, Симв(0), "");
        Если Стр <> СтрОчищенная Тогда
            Док.Комментарий = СтрОчищенная;
            Док.Записать();
        КонецЕсли;
    КонецЕсли;
КонецЦикла;

Проверка на циклические ссылки. Убедимся, что реквизиты документа не ссылаются на элементы справочников с зацикленной иерархией (когда родительский элемент ссылается сам на себя или на дочернюю группу).

Шаг 3. Подготовка настроек MS SQL Server и операционной системы

Корректная подготовка серверного окружения предотвратит системные сбои механизма выгрузки/загрузки:

Модель восстановления базы данных. В среде SQL Server Management Studio (SSMS) откроем свойства созданной базы данных, перейдем на вкладку «Options» и переключим параметр Recovery model в значение Simple (Простая). Это предотвратит лавинообразное разрастание файла журнала транзакций (.ldf) во время импорта.
Размеры файлов. Заранее выделим достаточный начальный размер файлов базы данных (например, 5–10 ГБ) с шагом авторасширения не менее 500 МБ, чтобы сервер не тратил ресурсы на постоянное перераспределение дискового пространства.
Исключения DEP (Data Execution Prevention). На операционных системах Windows Server 2008 R2 механизм DEP может принудительно выгружать процесс 1cv7s.exe при пиковой загрузке памяти. Добавим исполняемые файлы платформы 1С 7.7 в список исключений DEP в параметрах быстродействия системы.
Уровень совместимости и патчи. При использовании современных версий MS SQL Server (2008 R2 и выше) убедимся, что для платформы применен корректный модифицированный комплект библиотек («секретный релиз» / пропатченный BkEnd.dll), позволяющий корректно работать со структурой системных таблиц более новых СУБД. При этом принудительно понижать уровень совместимости базы данных не требуется.

Шаг 4. Альтернативный обход: секционный перенос

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

В рабочей копии DBF очистим только проблемные документы («Оказание услуг») с помощью групповой обработки удаления объектов или временно сделаем их непроведенными/помеченными на удаление.
Выполним штатную выгрузку базы через меню конфигуратора «Администрирование» — «Выгрузить данные».
Успешно загрузим очищенную базу в целевую СУБД MS SQL Server.
Перенесем только документы «Оказание услуг» из исходной базы в новую базу SQL порциями через внешнюю обработку обмена в формате XML или прямое подключение через OLE (объект V77.Application). При таком подходе ошибки в конкретных документах сразу отобразятся в журнале сообщений без прерывания загрузки всей базы.