← На главную

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

Причина 1. Недостаток прав учетной записи на SQL Server

Первая ошибка обычно возникает в самом начале процесса загрузки, когда конфигуратор 1С пытается пересоздать или обновить структуры таблиц и индексов на сервере баз данных. Если пользователю СУБД не хватает привилегий, процесс прерывается с ошибкой выполнения инструкции ALTER TABLE или создания объектов базы.

Разберем требования к правам учетной записи SQL:

1. Для пользователя, под которым платформа 1С подключается к базе данных, стандартных ролей уровня чтения и записи данных (db_datareader и db_datawriter) недостаточно. Пользователь обязательно должен обладать ролью db_owner для целевой базы данных.
2. При первичной инициализации и пересоздании базы через конфигуратор учетной записи на сервере SQL может потребоваться серверная роль dbcreator или права sysadmin для корректного выполнения системных DDL-скриптов.

Причина 2. Ошибка «Обнаружены дублирующиеся номера строк документа»

После настройки прав и повторной попытки загрузки процесс может прерваться ошибкой вставки данных из-за дублирования ключей в индексах. В окне сообщений платформа выдает предупреждение вида: «Документ.ХХХ Обнаружены дублирующиеся номера строк документа. Произведена перенумерация строк. ' 50'».

Проанализируем природу этой ошибки. В файловой версии формат DBF менее строго контролирует целостность связей. При многопользовательской работе, аварийных сбоях питания, разрывах сетевых соединений или включенном кэшировании (SMB Oplocks) файл таблицы документа может содержать строки с одинаковыми номерами, либо строки, некорректно помеченные на удаление. В MS SQL Server табличные части документов (таблицы с префиксом DT) имеют кластерный индекс по полям IDDOC (идентификатор документа) и LINENO_ (номер строки). При попытке загрузить одинаковые номера строк сервер СУБД блокирует транзакцию из-за нарушения уникальности первичного ключа.

Шаг 1. Локализация проблемного документа

В тексте системного сообщения конфигуратора в кавычках выводится идентификатор проблемного документа, дополненный пробелами слева (например, ' 50'). Это значение поля IDDOC.

Чтобы найти конкретный документ в исходной файловой базе, выполним следующие действия:

1. Откроем файловую базу в режиме «Конфигуратор» или воспользуемся любым DBF-редактором.
2. Откроем файл общего журнала 1SJOURN.DBF.
3. Выполним поиск по полю IDDOC, указав значение из ошибки (например, 50, с учетом лидирующих пробелов до 9 символов).
4. По найденной записи определяем дату, номер (поле DOCNO) и вид документа (поле IDDOCDEF).

Шаг 2. Исправление ошибок в файловой базе перед выгрузкой

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

1. Штатное пересохранение документа в режиме «1С:Предприятие». Откроем найденный проблемный документ в пользовательском режиме. Внесем небольшое изменение (например, допишем пробел в комментарии) и пересохраним документ. При штатной перезаписи формы платформа 1С автоматически восстанавливает непрерывную последовательность номеров строк в табличной части и перезаписывает их корректно.
2. Тестирование и исправление информационной базы. В режиме «Конфигуратор» запустим процедуру «Администрирование» — «Тестирование и исправление ИБ». Обязательно выберем режим «Тестирование и исправление» (а не только тестирование), установив флаги проверки логической и физической целостности. Платформа самостоятельно устранит расхождения нумерации строк и удалит фантомные записи.
3. Проверка документов с большим количеством строк. Если в базе присутствуют документы, содержащие более 9999 строк, это может провоцировать сбои нумерации и переполнение типов данных. Такие документы необходимо разбить на несколько более мелких перед процедурой миграции.
4. Физическая очистка и упаковка таблиц. Если документ поврежден настолько, что не открывается в пользовательском режиме, откроем таблицу его табличной части DT*.DBF, отфильтруем записи по IDDOC, устраним некорректные номера в колонке LINENO_ и выполним команду сжатия таблицы (Pack) для окончательного удаления физически помеченных на удаление строк.

Шаг 3. Подготовка и повторная загрузка в SQL

После того как исходные данные в файловой базе исправлены, выполним финализацию переноса:

1. В файловой базе выполним команду «Администрирование» — «Выгрузить данные» и сформируем новый файл архива.
2. На стороне SQL Server полностью очистим или пересоздадим пустую базу данных, так как незавершенная попытка загрузки оставляет в таблицах часть незафиксированных данных.
3. Запустим конфигуратор 1С с подключением к SQL-базе и выполним операцию «Администрирование» — «Загрузить данные».

Такой последовательный подход гарантирует устранение структурных расхождений и обеспечивает корректный перенос данных в клиент-серверную базу без потерь информации.