Как отключить COM-соединение в 1С

COM-соединение в 1С — это механизм, при котором одна база (или внешняя программа) подключается к другой базе через объект V83.COMConnector и работает с её данными как изнутри. Пока соединение открыто, целевая база удерживает сеанс, потребляет память сервера и может блокировать регламентные операции. Поэтому корректное отключение COM-соединения — обязательная часть любой интеграции, а не формальность.

Проблема чаще всего проявляется так: обмен через COM отработал, но в консоли кластера или в списке активных пользователей остаётся «висящий» сеанс фонового пользователя, монопольный режим не удаётся установить, а файл 1Cv8.1CL либо журналы продолжают расти. Причина почти всегда одна — соединение не было явно разорвано, и объект-коннектор продолжает жить в памяти вызывающего процесса.

Ниже разобраны способы отключения COM-соединения: штатное закрытие из кода 1С, принудительное завершение сеанса через консоль кластера, работа с зависшими процессами и профилактика повторных «зависаний». Материал применим к файловым и клиент-серверным базам на платформе 8.3.

Как устроено COM-соединение и почему оно не закрывается само

При вызове Новый COMОбъект("V83.COMConnector") создаётся внешний компонент, который устанавливает соединение методом Connect(СтрокаПодключения). Результат — объект типа COM-соединение, через который доступны менеджеры объектов целевой базы. С точки зрения целевой базы это полноценный сеанс: он виден в консоли кластера, занимает лицензию и держит соединение с СУБД в клиент-серверном варианте.

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

Вторая причина «вечных» сеансов — исключения. Если код обмена упал с ошибкой до строки отключения, а объект соединения объявлен вне попытки и не обнулялся, сеанс в целевой базе останется активным, пока не завершится процесс-владелец коннектора или не сработает таймаут кластера.

Штатное отключение COM-соединения из кода 1С

Штатный способ — не вызов специального метода «Disconnect» (его у COM-соединения нет), а освобождение всех ссылок на объект соединения и на сам коннектор. Как только последняя ссылка исчезает, платформа разрушает объект, и сеанс в целевой базе закрывается.

Рекомендуемый шаблон выглядит так: соединение создаётся внутри попытки, работа ведётся в ней же, а в блоке «Исключение» и после успешного завершения переменные явно обнуляются. Это гарантирует разрыв и при ошибке, и при нормальном завершении.

Процедура ВыполнитьОбмен()
    Коннектор = Неопределено;
    Соединение = Неопределено;
    Попытка
        Коннектор = Новый COMОбъект("V83.COMConnector");
        Соединение = Коннектор.Connect(СтрокаПодключения);
        // ... работа с данными ...
    Исключение
        ЗаписьЖурналаРегистрации("Обмен", УровеньЖурналаРегистрации.Ошибка,,, ОписаниеОшибки());
    КонецПопытки;
    // Отключение COM-соединения
    Соединение = Неопределено;
    Коннектор = Неопределено;
КонецПроцедуры

Обратите внимание на порядок: сначала обнуляется переменная соединения, затем коннектор. Если соединение хранилось в нескольких местах (реквизит формы, параметр, соответствие кэша), очистить нужно все ссылки, иначе объект продолжит жить. После обнуления в толстом клиенте можно дополнительно не вызывать ничего — сборка мусора платформы выполнит разрушение при освобождении контекста.

Проверка результата: после завершения процедуры откройте консоль кластера целевой базы (или «Активные пользователи» в файловом варианте) — сеанс COM-подключения должен исчезнуть в течение короткого времени. Если сеанс остался, значит где-то сохранилась лишняя ссылка на объект.

1. 1
   Найдите в коде все переменные и реквизиты, хранящие объект соединения и коннектор
2. 2
   Оберните работу в Попытка/Исключение/КонецПопытки
3. 3
   После блока присвойте соединению и коннектору значение Неопределено
4. 4
   Очистите кэширующие структуры (соответствия, реквизиты обработки), где могла остаться ссылка
5. 5
   Запустите обмен и проверьте в консоли кластера, что сеанс закрылся

Отключение зависшего сеанса через консоль кластера

Если код уже отработал и исправить его «задним числом» нельзя, зависший сеанс завершается административно. Для клиент-серверной базы откройте консоль администрирования серверов 1С, раскройте нужный кластер, перейдите в раздел «Сеансы», найдите сеанс с приложением «COM-соединение» (в колонке «Приложение» обычно указано COMConnection или имя фонового задания) и удалите его через контекстное меню.

Перед удалением проверьте, что сеанс действительно бездействует: в свойствах сеанса видно время последнего обращения и объём прочитанных/записанных данных. Если активность идёт прямо сейчас — это не зависший, а работающий обмен, и его разрыв приведёт к ошибке в вызывающей программе и возможной рассинхронизации данных.

В файловом варианте консоли кластера нет. Здесь сеанс COM-соединения удерживается процессом, в котором создан коннектор: чаще всего это 1cv8.exe на машине, запустившей обмен, либо rphost, если обмен выполняется фоновым заданием на сервере. Завершение такого сеанса — это завершение процесса-владельца, поэтому сначала убедитесь, что процесс не выполняет других полезных задач.

Отключение через консоль заданий и «Активные пользователи»

Если COM-соединение открыто из базы-приёмника по отношению к базе-источнику, в базе-источнике активный сеанс виден в стандартной форме «Активные пользователи» (в типовых конфигурациях — раздел «Администрирование»). Там можно посмотреть, кто и когда подключился, но штатной кнопки принудительного завершения чужого сеанса в файловом варианте нет — только в клиент-серверном через консоль кластера.

Если обмен запускается регламентным заданием, полезно проверить консоль заданий: возможно, задание «висит» в состоянии выполнения и держит соединение. Завершение такого фонового задания (через консоль кластера — раздел «Задания») освободит и COM-сеанс в целевой базе.

Типичные ошибки при отключении COM-соединения

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

Вторая ошибка — обнуление только коннектора при живой переменной соединения. Пока существует объект, возвращённый методом Connect, сеанс в целевой базе активен. Обнулять нужно обе ссылки, причём во всех местах, где они сохранялись.

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

Альтернативы COM-соединению и когда стоит от него уйти

COM-соединение — не единственный и далеко не всегда лучший способ интеграции. Если зависшие сеансы и проблемы с лицензиями возникают регулярно, рассмотрите замену. HTTP-сервисы и веб-сервисы целевой базы не создают постоянного сеанса: соединение живёт только на время запроса, и проблема «забыли отключить» исчезает в принципе.

Для обменов между типовыми конфигурациями предпочтительны планы обмена и механизмы EnterpriseData через файлы или брокеры сообщений — там нет прямого подключения к чужой базе вообще. COM остаётся оправданным для разовых операций, миграций и административных обработок, где нужен полный доступ к объектной модели целевой базы.

Профилактика: как не допустить зависания сеансов

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

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

Частые вопросы