При обновлении инфраструктуры 1С часто возникает задача массового перевода большого количества информационных баз со старой платформы «1С:Предприятие 8.1» на современную «1С:Предприятие 8.3». Если баз много, ручной интерактивный запуск Конфигуратора для каждой из них отнимает слишком много времени. Разберем технические особенности, архитектурные ограничения и пошаговый алгоритм решения этой задачи.
Проанализируем ключевые ограничения платформы, с которыми сталкиваются администраторы при попытке автоматизировать конвертацию:
CONFIG платформа выводит модальное диалоговое окно с запросом подтверждения конвертации. Передать автоматическое согласие через стандартные параметры запуска невозможно.cnvdbfl.exe. Однако для клиент-серверных баз на СУБД (MS SQL Server, PostgreSQL, Oracle, IBM DB2) эта утилита неприменима, так как она работает исключительно с файлами 1Cv8.1CD.Если ваши информационные базы работают в файловом режиме, рассмотрим наиболее быстрый и удобный способ конвертации через встроенную утилиту платформы. В каталоге установки 1С (папка bin) найдем файл cnvdbfl.exe.
Посмотрим на синтаксис команды:
"C:\Program Files\1cv8\8.3.X.X\bin\cnvdbfl.exe" -c -f 8.3.8 "D:\Bases\MyBase\1Cv8.1CD"
Параметр -c запускает процедуру конвертации, а параметр -f указывает целевую версию формата файла. Этот способ позволяет написать простой пакетный файл (BAT/PowerShell) и обработать любое количество файловых баз полностью в фоновом режиме.
Для баз, работающих под управлением СУБД, утилита cnvdbfl.exe не подходит. Разберем правильный и надежный регламент перехода.
Убедимся, что в базе 8.1 приняты все изменения конфигурации (конфигурация базы данных совпадает с основной конфигурацией). Если конфигурация разработчика не сохранена в базу данных, процесс конвертации завершится аварийно. Также крайне рекомендуется выполнить тестирование и исправление (ТИИ) для устранения логических ошибок и битых ссылок.
На сервере должен быть поднят кластер «1С:Предприятие 8.2». Если службы 8.1, 8.2 и 8.3 работают на одном физическом сервере, настроим для них разные диапазоны сетевых портов (например, 1540/1541 для 8.1 и 1640/1641 для 8.2). В консоли администрирования 8.2 создаем новую информационную базу, указываем параметры существующей базы на SQL-сервере и обязательно снимаем флаг «Создать базу данных в случае ее отсутствия».
Запускаем Конфигуратор платформы 8.2 и подтверждаем диалог обновления формата базы данных. Платформа 8.2 выполнит реструктуризацию таблиц СУБД под свои стандарты.
После успешной конвертации в 8.2 регистрируем информационную базу в кластере серверов 8.3. Платформа 8.3 откроет базу 8.2 в режиме совместимости без необходимости сложной повторной реструктуризации.
Поскольку при открытии Конфигуратора 8.2 требуется нажать кнопку подтверждения в диалоговом окне, автоматизировать процесс для 100+ баз можно с помощью скриптовых утилит эмуляции пользовательского ввода (AutoIt или AutoHotkey).
Однако при работе скриптов автоматизации графического интерфейса возникает проблема: при блокировке рабочего стола Windows (Lock Screen) или отключении RDP-сессии подсистема GUI перестает передавать нажатия клавиш окнам. Выясним причину: при разрыве RDP сессия переходит в неинтерактивный режим.
Чтобы скрипты автоматизации корректно отрабатывали в нерабочее время без активного пользователя за монитором, примените один из следующих подходов:
Перед тем как закрыть удаленный рабочий стол, выполним в командной строке от имени администратора перенаправление сессии:
tscon %sessionname% /dest:console
После выполнения этой команды интерактивный рабочий стол останется активным в памяти сервера, и скрипты AutoIt смогут нажимать кнопки в окнах Конфигуратора.
Настроим временную виртуальную машину для административных задач, отключим на ней автоматическую блокировку экрана и скринсейвер, после чего запустим сценарий пакетной обработки.
Если вам необходимо уложиться в жесткое технологическое окно (например, 4–6 часов на 100–150 баз), последовательная конвертация может занять слишком много времени. Проанализируем нагрузку на дисковую подсистему и процессор сервера СУБД: процесс конвертации упирается преимущественно в скорость дисков и блокировки таблиц конкретной базы. Запуск скрипта конвертации параллельно в 4–8 потоков (обрабатывая одновременно разные базы) позволяет многократно сократить общее время технологического перехода.