← На главную

Перевод информационной базы с редакции Бухгалтерия предприятия 2.0 на редакцию 3.0 — это масштабная процедура, при которой полностью перестраивается структура хранения данных. Нередко в процессе обновления конфигурации Конфигуратор закрывается «молча» без вывода диагностических сообщений об ошибке. Чаще всего сбой происходит на этапе реструктуризации справочника Справочник.Контрагенты, когда предыдущие таблицы (документы, регистры бухгалтерии и накопления) уже успешно обработаны.

Разберем основные причины такого поведения платформы «1С:Предприятие» и рассмотрим проверенные способы устранения проблемы.

Причины аварийного завершения Конфигуратора

Проанализируем, почему падение происходит именно на справочнике контрагентов:

1. Ошибки управления памятью в конкретных сборках платформы: В некоторых релизах платформы (в частности, в ветке 8.3.11) при реструктуризации больших файловых таблиц и фоновой обработке возникают внутренние ошибки выделения памяти, приводящие к аварийному завершению процесса 1cv8.exe.
2. Превышение лимита адресного пространства 32-разрядного процесса: В файловом варианте работы толстый клиент и Конфигуратор работают как 32-битные приложения. Адресное пространство процесса ограничено 2 ГБ. При обновлении массивного справочника с множеством контактных данных память переполняется.
3. Кардинальная трансформация контактной информации: При переходе на редакцию 3.0 контактная информация контрагентов переносится на механизмы Библиотеки стандартных подсистем (БСП) с разбором адресов по новым форматам. Некорректные символы или поврежденные XML-структуры в адресах редакции 2.0 могут приводить к критическому сбою парсера при реструктуризации.

Способ 1. Смена версии платформы 1С:Предприятие

Самое быстрое и эффективное решение проблемы, когда тестирование и исправление утилитой chdbfl.exe и штатным тестированием базы не выявляет ошибок, — выполнение реструктуризации на другой, проверенной версии платформы.

Разберем по шагам, как выполнить переход:

1. Определим минимальные и рекомендуемые требования релиза конфигурации к платформе (указываются в файле ReadMe.txt к дистрибутиву обновления). Например, для релизов ветки 3.0.57 целесообразно использовать платформу линейки 8.3.10 (релиз 8.3.10.2505, 8.3.10.2667) вместо нестабильных сборок 8.3.11.
2. Установим требуемый релиз платформы на рабочий компьютер.
3. Запустим Конфигуратор базы редакции 2.0 именно под этой версией платформы.
4. Повторим процедуру обновления конфигурации через меню Конфигурация — Поддержка — Обновить конфигурацию или загрузкой подготовленного файла .cf.
5. Применим изменения структуры конфигурации (клавиша F7) и дождемся завершения реструктуризации.

Способ 2. Выполнение реструктуризации в 64-разрядном клиент-серверном режиме

Если смена релиза платформы не помогла из-за огромного объема данных справочника Контрагенты, ограничение 32-битного адресного пространства файловой базы можно обойти переводом базы в SQL-среду на время обновления.

Рассмотрим порядок действий:

1. Выгрузим исходную базу редакции 2.0 в файл выгрузки .dt через меню Администрирование — Выгрузить информационную базу.
2. Развернем пустую базу на 64-разрядном сервере «1С:Предприятия» под управлением СУБД (PostgreSQL или MS SQL Server).
3. Загрузим .dt в клиент-серверную базу.
4. Выполним обновление конфигурации на редакцию 3.0 в клиент-серверном режиме. 64-разрядный сервер 1С не имеет ограничений по памяти на процесс и успешно завершит реструктуризацию сложных таблиц.
5. Запустим базу в режиме «1С:Предприятие» для выполнения начальных процедур обновления данных БСП.
6. После завершения всех регламентных процедур выгрузим обновленную базу обратно в .dt и загрузим в файловый вариант, если дальнейшая эксплуатация планируется без сервера СУБД.

Способ 3. Очистка адресных сведений перед обновлением

Для уменьшения объема обрабатываемых таблиц и исключения сбоев при конвертации адресных данных рекомендуется оптимизировать исходную базу 2.0 перед накатыванием обновления:

1. В исходной базе 2.0 откроем форму управления адресным классификатором и очистим неиспользуемые регионы КЛАДР.
2. Выполним поиск и удаление помеченных на удаление объектов, чтобы дублирующие и неактуальные элементы справочника Контрагенты не участвовали в реструктуризации.
3. Проверим табличную часть контактной информации контрагентов на наличие недопустимых спецсимволов и управляющих последовательностей.

Альтернативный вариант: Перенос данных в чистую базу 3.0

Если реструктуризация исходной базы «накатом» продолжает завершаться аварийно из-за накопленных за годы ошибок в таблицах данных, рассмотрим альтернативный путь перехода:

1. Создадим новую пустую информационную базу актуального релиза конфигурации «Бухгалтерия предприятия 3.0».
2. Используем типовую обработку переноса данных (мастер перехода с 2.0 на 3.0), которая выгружает через XML только справочники, остатки на начало выбранного периода и документы за открытый период.
3. Такой подход полностью исключает падения на этапе физической реструктуризации таблиц СУБД и очищает базу от устаревшего системного мусора.