← На главную

При переходе с конфигурации «Бухгалтерия предприятия» редакции 2.0 на версию 3.0 специалисты часто сталкиваются с критическим сбоем. В процессе реструктуризации базы данных (часто на объекте ДоговорыКонтрагентов) Конфигуратор 1С аварийно завершает работу с ошибкой в модуле basic.dll. Обычные профилактические процедуры — такие как тестирование и исправление (ТИИ), выгрузка/загрузка информационной базы в .dt или очистка кэша — в данной ситуации не дают результата.

Разберем причины возникновения этой проблемы, проанализируем ошибки схемы базы данных и рассмотрим проверенные алгоритмы восстановления процесса обновления.

Причины сбоя в basic.dll и ошибки SDBL

Выясним, почему происходят сбои при изменении структуры данных:

1. Ошибка в релизе платформы: В некоторых релизах технологической платформы ветки 8.3.11 (в частности 8.3.11.2954 и 8.3.11.3034) присутствуют внутренние проблемы ядра при обработке тяжелых процессов реструктуризации. Модуль basic.dll отвечает за базовые типы данных и память, и при изменении сложных справочников с высокой плотностью связей происходит сбой процесса.
2. Ограничение адресного пространства 32-разрядного Конфигуратора: Процесс Конфигуратора при обновлении крупных справочников может превышать лимит выделения оперативной памяти в 2 ГБ, что приводит к падению программы.
3. Рассинхронизация схемы СУБД (Ошибка SDBL): Если при попытке обхода ошибки вручную отключить режим совместимости в БП 2.0, платформа выдает ошибку: «Ошибка SDBL: В схеме базы данных нет таблицы с именем ExtensionsRestruct». Это происходит из-за того, что служебный файл схемы dbschema запрашивает системные таблицы для работы с расширениями, которые еще не были физически созданы в СУБД из-за незавершенной реструктуризации.

Основное решение: Переход на технологическую платформу 8.3.10

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

1. Создание резервной копии: Сделаем полную копию рабочей базы данных (выгрузку в файл .dt или резервную копию средствами MS SQL Server / PostgreSQL).
2. Установка платформы 8.3.10: Установим на рабочую станцию администратора релиз платформы версии 8.3.10 (например, 8.3.10.2699). Менять версию платформы на основном сервере 1С для всех пользователей при этом не требуется.
3. Перевод базы в файловый режим (опционально): Для исключения влияния серверных процессов выгрузим базу в файловый вариант и запустим Конфигуратор через установленный релиз 8.3.10.
4. Выполнение обновления:

   В Конфигураторе платформы 8.3.10 выполним обновление конфигурации:

   Перейдем в меню Конфигурация — Поддержка — Обновить конфигурацию и укажем файл обновления переходного релиза БП 3.0 (например, 3.0.58.20 или специальный релиз для перехода).

   Применим изменения конфигурации и дождемся завершения реструктуризации таблиц СУБД.

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

Альтернативные и дополнительные методы решения

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

1. Использование 64-разрядного Конфигуратора: Если аварийное завершение связано с нехваткой оперативной памяти 32-битного процесса 1cv8.exe, запустим процесс обновления с помощью 64-разрядного клиента 1С:Предприятие.
2. Проверка целостности утилитой chdbfl.exe: Для файлового варианта перед обновлением запустим утилиту проверки физической целостности chdbfl.exe из каталога bin установленной платформы. Для серверных баз выполним проверку целостности средствами СУБД (команда DBCC CHECKDB для MS SQL).
3. Пошаговое последовательное обновление: Не следует обновлять устаревший релиз БП 2.0 сразу на крайнюю версию БП 3.0. Проверим файл UpdInfo.txt в дистрибутиве обновления и убедимся, что текущий релиз 2.0 официально поддерживает прямой переход на выбранный релиз 3.0. При необходимости выполним промежуточные обновления редакции 2.0.
4. Очистка временных файлов и кэша: Удалим кэш конфигуратора и сеансовых данных. Очистим каталоги:

   %LocalAppData%\1C\1Cv8

   %AppData%\1C\1Cv8

Таким образом, использование стабильного релиза платформы (например, 8.3.10) для выполнения процедуры реструктуризации позволяет успешно завершить переход с Бухгалтерии предприятия 2.0 на 3.0 без потери данных и ошибок СУБД.