Как решить проблему с вылетом и зависанием Конфигуратора при обновлении старой «1С:Управление торговлей 10.3» на платформе 8.3

← На главную

Перевод и последующее обновление старых конфигураций, разработанных во времена платформы «1С:Предприятие 8.2» (и даже 8.1), на современную платформу «1С:Предприятие 8.3» — задача, полная скрытых технических нюансов. Типичный сценарий: при попытке обновить очень старый релиз «Управление торговлей», редакция 10.3 (например, 10.3.10.4), запущенный на платформе 8.3, Конфигуратор либо молча закрывается без вывода ошибок, либо зависает на этапе реструктуризации базы данных.

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

Почему Конфигуратор «молча» вылетает при обновлении?

Для начала выясним причины, по которым Конфигуратор завершает работу аварийно и без видимых сообщений. В процессе сравнения, объединения и последующей реструктуризации метаданных система выполняет огромный объем вычислений в оперативной памяти. Существует несколько основных факторов, приводящих к сбою:

Ограничение разрядности Конфигуратора (32-бит). Традиционный Конфигуратор в старых версиях платформы 1С является 32-разрядным приложением. Это означает, что операционная система выделяет ему максимум 2 ГБ (в редких случаях при специальной настройке — до 3–4 ГБ) адресного пространства оперативной памяти. При сравнении огромных конфигураций (а «Управление торговлей» содержит тысячи объектов) или при накате «тяжелых» обновлений потребление памяти лавинообразно растет. Когда лимит исчерпывается, операционная система принудительно завершает процесс 1cv8.exe без возможности записать лог ошибки.
Глючные релизы платформы 1С. В нашей практической ситуации фигурирует релиз платформы 8.3.13.1513. В сообществе разработчиков ветка 8.3.13 (и особенно данный релиз) признана одной из самых нестабильных с точки зрения утечек памяти при реструктуризации баз данных. Использование устаревших или нестабильных версий платформы кратно увеличивает вероятность «тихого» падения системы.
Ограничения файлового формата базы данных. В файловой СУБД (файл 1Cv8.1CD) размер одной таблицы не может превышать 4 ГБ. Во время реструктуризации таблиц Конфигуратор создает временные копии таблиц базы данных для переноса информации. Если ваша исходная файловая база имеет внушительный объем, этот лимит мгновенно превышается, что приводит к критическому сбою СУБД (Runtime Error) и аварийному закрытию программы.

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

Шаг 1. Перенос базы данных на СУБД SQL

Если ваша база данных имеет большой размер и вы пытаетесь обновить её в файловом варианте, Конфигуратор с высокой долей вероятности продолжит вылетать. Наш опыт показывает, что перевод базы в клиент-серверный вариант (MS SQL Server, PostgreSQL) решает большинство проблем с нехваткой памяти и ограничениями таблиц. На SQL-сервере все тяжелые операции по изменению структуры таблиц берет на себя СУБД, снимая нагрузку с клиента.

Важное примечание по поводу «зависания» на 13% (или любом другом проценте): под управлением SQL-сервера процесс обновления базы данных может казаться зависшим (серое окно, отсутствие реакции интерфейса). На самом деле в этот момент СУБД выполняет сложнейшие SQL-транзакции: перестраивает индексы, создает новые колонки и переносит миллионы строк данных. Категорически запрещено принудительно завершать процесс Конфигуратора или службу сервера 1С в этот момент! Прерывание транзакции может привести к повреждению структуры базы данных или к экстремально долгому откату изменений СУБД (который может занять несколько часов).

Шаг 2. Использование правильной последовательности обновления платформ и конфигураций

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

Обновляйте конфигурацию на старой платформе до тех пор, пока сама конфигурация не потребует новую платформу!

Рассмотрим этот алгоритм подробнее:

Восстановите резервную копию базы на платформе 8.2 (желательно использовать наиболее стабильный релиз платформы 8.2, например, 8.2.19.130).
Последовательно обновляйте «Управление торговлей 10.3» по релизам. Для этого используйте файлы обновлений (.cfu) или полные конфигурации (.cf).
Доведите конфигурацию до релиза 10.3.53.2 (или аналогичного финального в ветке, которая еще поддерживает работу на платформе 8.2 в режиме совместимости Версия 8.2.16).
Только после того, как конфигурация обновлена до стабильного «переходного» релиза, перенесите базу данных на платформу 8.3.

Шаг 3. Контроль режима совместимости

При переходе на платформу 8.3 критически важно отслеживать свойство конфигурации «Режим совместимости». Если вы резко отключите совместимость или установите слишком высокое значение (например, сразу перейдете с совместимости 8.2.13 на «Не использовать»), система выдаст множество ошибок:

Произойдет сбой механизмов регистрации изменений (ошибки SDBL с таблицами регистрации изменений, константами и т.д.).
Код, использующий старые функции работы со значениями (например, особенности работы с пустыми значениями в запросах или обработчиках типа ОбработкаЗаполнения), начнет работать некорректно.
Потребуется перевод базы в режим управляемых блокировок, так как старый автоматический режим блокировок на новых версиях платформы без совместимости может вызывать транзакционные ошибки.

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

Шаг 4. Обновление через «чистый» файл конфигурации (CF)

Если Конфигуратор продолжает падать при пошаговом накатывании файлов обновлений .cfu, рекомендуется прибегнуть к методу «чистого» объединения через полный файл конфигурации .cf. Выполните следующие шаги:

Разверните на вашей текущей платформе абсолютно чистую базу целевого релиза (без данных) из официального дистрибутива «1С».
Выгрузите из этой чистой базы файл конфигурации (меню Конфигурация -> Сохранить конфигурацию в файл...) и получите чистый .cf.
Откройте вашу рабочую базу в Конфигураторе. Включите возможность изменения (если конфигурация была доработана) или снимите её с поддержки, если доработки больше не требуются.
Выполните сравнение и объединение с полученным чистым файлом .cf (меню Конфигурация -> Сравнить, объединить с конфигурацией из файла...).
В открывшемся окне сравнения снимите флажки с тех объектов, в которые были внесены ваши уникальные доработки (чтобы не затереть их), либо полностью примите конфигурацию поставщика, если база должна стать типовой.
Выполните сохранение и обновите конфигурацию базы данных (клавиша F7).

Шаг 5. Смена версии платформы на более стабильную

Если вы вынуждены выполнять работы на платформе 8.3, забудьте про нестабильные релизы вроде 8.3.13.1513. Для проведения тяжелых процедур реструктуризации установите современную 64-битную платформу (например, актуальные релизы веток 8.3.21, 8.3.22 или выше).

64-разрядный Конфигуратор лишен проблемы ограничения адресного пространства в 2 ГБ и может задействовать всю свободную оперативную память сервера или персонального компьютера, что полностью исключает «тихие» вылеты по причине нехватки ресурсов (Out of memory).

Подводя итог, отметим: успешное обновление старых систем всегда строится на трех столпах — перенос на СУБД SQL для обхода ограничений файлового формата, использование стабильных 64-битных платформ и строгое соблюдение эволюционного пути обновления конфигурации без резких скачков версий совместимости.