Почему не работает обмен через ADO после обновления на платформу 1С 19 и выше?

← На главную

В процессе обновления инфраструктуры 1С:Предприятие часто возникают ситуации, когда проверенные годами механизмы взаимодействия со сторонними базами данных через ADODB перестают функционировать. Рассмотрим подробнее, с чем это связано и как проанализировать проблему, если после перехода на 19 или 20 платформу ваши обмены, в частности с Альфа-Авто, начинают «зависать».

Анализ ситуации: выявление причин зависания

Первое, что мы должны сделать — исключить фактор прав доступа и разрядности. Как показала практика, если на 18 платформе обмен работал под теми же учетными записями, то проблема с вероятностью 99% кроется в изменениях внутри самой платформы 1С. Основные причины, которые мы можем выделить:

Отказ от устаревших технологий: 1С постепенно минимизирует использование COM-объектов для обеспечения кроссплатформенности и работы на Linux.
Проблемы потоковой модели: COM-объекты требуют наличия очереди сообщений (STA-модель), в то время как серверные процессы 1С работают в многопоточном режиме (MTA). Несовпадение потоков приводит к «вечному» ожиданию ответа от объекта ADODB.
Безопасность: Новые политики безопасности платформы могут блокировать вызовы, которые ранее выполнялись неявно.

Как проверить работоспособность COM-объектов

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

Тестирование через внешние инструменты: Используйте портативные инструменты разработчика для 1С, которые позволяют выполнить код вне контекста вашего сложного обмена.
Локализация: Попробуйте выполнить вызов объекта в файловой базе. Если в файловой версии ADODB работает, а в клиент-серверной нет — проблема точно на стороне взаимодействия сервера 1С с Windows COM.
Проверка регистрации: Убедитесь, что требуемая библиотека ADODB (обычно msado15.dll) корректно зарегистрирована в системе и сервер 1С имеет к ней доступ.

Варианты обхода ограничений

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

1. Использование `MsScriptControl`

Иногда обертка вызова через MsScriptControl помогает, так как этот объект самостоятельно управляет очередью сообщений, что может предотвратить «зависание» потока. Попробуем реализовать такой подход:


// Пример логики создания объекта через ScriptControl
Скрипт = Новый COMОбъект("MSScriptControl.ScriptControl");
Скрипт.Language = "VBScript";
Скрипт.AddCode("
    Function GetConnection()
        Set conn = CreateObject(""ADODB.Connection"")
        conn.Open ""ВашаСтрокаПодключения""
        Set GetConnection = conn
    End Function
");
Подключение = Скрипт.Run("GetConnection");

2. Переход на нативные решения

Если мы хотим добиться максимальной стабильности, рекомендуется отказаться от COM-объектов в пользу специализированных библиотек (Native API). Это позволит нам не зависеть от архитектурных ограничений Windows и настроек прав DCOM.

3. Изоляция вызовов в микросервисы

Если обновление платформы критично, а отказ от ADODB невозможен, проанализируем вариант выноса обмена в отдельное консольное приложение. Это позволит запускать процесс через ЗапуститьПриложение(). Такой подход изолирует COM-вызовы, и даже если они «зависнут», основной процесс сервера 1С останется работоспособным.