Почему подключение по ADO к SQL базе работает в БП 3.0, но выдает ошибку в УТ 10.3?

← На главную

При интеграции систем 1С со сторонними базами данных Microsoft SQL Server программисты часто используют технологию ADO (ActiveX Data Objects). Это проверенный временем и удобный способ напрямую читать или записывать данные в стороннюю СУБД. Однако на практике разработчики нередко сталкиваются с ситуацией, когда один и тот же код интеграции с абсолютно идентичной строкой подключения без проблем отрабатывает в «Бухгалтерии предприятия 3.0» (БП 3), но завершается аварийно в «Управлении торговлей 10.3» (УТ 10).

При попытке установить соединение в УТ 10 система выдает классическую ошибку: «Ошибка при вызове метода контекста (Open): Произошла исключительная ситуация (ADODB.Connection): Не удается найти указанный поставщик. Вероятно, он установлен неправильно». Давайте подробно проанализируем причины этой проблемы и разберем по шагам все возможные способы ее решения.

Выясняем причину: почему поведение конфигураций различается?

Для того чтобы понять, почему возникает эта ошибка, нам необходимо детально рассмотреть архитектурные различия между БП 3 и УТ 10, а также особенности работы COM-объектов в операционной системе Windows. Проблема кроется на стыке двух ключевых факторов: контекста выполнения кода и разрядности (битности) процессов.

1. Контекст выполнения кода (Клиент-Сервер)

Современная конфигурация БП 3 построена на управляемых формах. В ней практически вся бизнес-логика и тяжелые операции, включая подключение к внешним источникам данных через &НаСервере, выполняются непосредственно на сервере 1С:Предприятия. Это означает, что инициализация COM-объекта ADODB.Connection происходит внутри серверного процесса rphost.exe на сервере приложений.

Конфигурация УТ 10, напротив, спроектирована на обычных формах (толстый клиент). В ней программный код по умолчанию выполняется в контексте клиентского приложения на локальном компьютере пользователя или в его терминальной сессии. Таким образом, при запуске одного и того же кода БП 3 обращается к провайдерам данных, установленным на сервере, а УТ 10 — к провайдерам, установленным на конкретной рабочей станции пользователя.

2. Проблема разрядности (32-bit против 64-bit)

Сервер приложений 1С в подавляющем большинстве случаев устанавливается в 64-разрядной версии. Соответственно, процесс rphost.exe является 64-битным и может использовать только 64-битные версии OLE DB-провайдеров, зарегистрированных в операционной системе Windows.

С клиентскими компьютерами ситуация иная. Очень часто на рабочих местах пользователей развернут 32-битный толстый клиент 1С (x86). 32-битный процесс физически не способен взаимодействовать с 64-битными COM-объектами и драйверами СУБД из-за особенностей адресации памяти в Windows. Если на компьютере пользователя установлен только 64-битный драйвер SQL Server (или драйвер вообще отсутствует), то 32-битное клиентское приложение 1С выдаст ошибку о невозможности найти указанного поставщика данных.

---

Варианты решения проблемы

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

Решение 1. Установка правильного драйвера Native Client на рабочие станции

Если код ADO-подключения в УТ 10 должен выполняться строго на стороне клиента (например, если база файловая или требуется локальное обращение), необходимо обеспечить наличие нужного драйвера в операционной системе пользователя.

Выясним разрядность платформы 1С на клиентском ПК. Если используется 32-битная версия 1С, вам необходимо скачать и установить именно 32-разрядный (x86) Microsoft SQL Server Native Client. Если используется 64-битная версия 1С — устанавливайте 64-разрядный (x64) пакет.

Для обеспечения стабильной работы в гетерогенных средах (например, на терминальном сервере, где пользователи могут запускать как 32-битные, так и 64-битные версии клиентов) настоятельно рекомендуется установить обе версии драйверов — и x86, и x64.

Решение 2. Перенос выполнения ADO-кода на сторону сервера

Если база данных УТ 10 работает в клиент-серверном режиме, наиболее изящным и правильным решением будет перенос логики подключения на сервер 1С. В этом случае отпадет необходимость устанавливать и администрировать SQL-драйверы на десятках клиентских компьютеров.

Разберем этот процесс по шагам:

Создадим в конфигураторе УТ 10 новый общий модуль или выберем существующий (например, создадим модуль ИнтеграцияСВнешнимиБазамиСервер).
В свойствах общего модуля обязательно установим флаг Сервер и снимем флаги Клиент (обычное приложение) и Клиент (управляемое приложение). Также установим флаг Вызов сервера, чтобы клиентский код мог обращаться к экспортным методам этого модуля.
Перенесем весь код создания COM-объекта и выполнения SQL-запросов в этот модуль.

Посмотрим на пример реализации такого серверного метода:


// Функция выполняется на сервере 1С
Функция ВыполнитьЗапросКСтороннейБД(СтрокаПодключения, ТекстЗапроса) Экспорт
    
    Соединение = Новый COMОбъект("ADODB.Connection");
    НаборЗаписей = Новый COMObьект("ADODB.Recordset");
    
    Попытка
        Соединение.Open(СтрокаПодключения);
    Исключение
        ЗаписьЖурналаРегистрации("Интеграция.ADO", УровеньЖурналаРегистрации.Ошибка,,, 
            "Не удалось подключиться к базе данных. Описание ошибки: " + ОписаниеОшибки());
        ВызватьИсключение "Ошибка подключения к внешней СУБД. Обратитесь к администратору.";
    КонецПопытки;
    
    // Код выполнения запроса и обработки данных...
    // Соединение.Close();
    
КонецФункции

При таком подходе клиентское приложение УТ 10 лишь отправляет серверу команду, сервер производит подключение через установленный у него 64-битный драйвер (который уже настроен и гарантированно работает, так как БП 3 успешно подключается) и возвращает результат клиенту.

Решение 3. Использование универсальных или современных провайдеров в строке подключения

Иногда проблема кроется в самом провайдере, указанном в строке подключения. В предоставленном примере используется SQLNCLI11 (Microsoft SQL Server Native Client 11.0). Этот драйвер считается устаревшим и не всегда присутствует в современных операционных системах по умолчанию.

Рассмотрим альтернативные варианты строк подключения, которые помогут обойти проблему:

Вариант А. Системный провайдер SQLOLEDB

Это классический стандартный провайдер OLE DB для SQL Server. Его главное преимущество заключается в том, что он поставляется вместе с операционной системой Windows и присутствует как в 32-битных, так и в 64-битных версиях ОС «из коробки». Вам не придется ничего скачивать и устанавливать на клиентах.

Посмотрим, как изменится строка подключения:


СтрокаПодключения = "Provider=SQLOLEDB;Data Source=ИмяСервера;Initial Catalog=ИмяБазы;User ID=Логин;Password=Пароль;";

Важное примечание: Данный провайдер не поддерживает новые типы данных и специфические фичи современных версий MS SQL Server (начиная с SQL Server 2012 и выше), однако для простых запросов получения и записи данных он подходит идеально.

Вариант Б. Современный драйвер Microsoft OLE DB Driver for SQL Server (MSOLEDBSQL)

Microsoft выпустила новый, активно поддерживаемый драйвер MSOLEDBSQL взамен устаревшего Native Client. Если вы хотите использовать самые современные возможности СУБД, скачайте этот драйвер с официального сайта Microsoft и установите его на клиентские ПК (или сервер). Строка подключения примет следующий вид:


СтрокаПодключения = "Provider=MSOLEDBSQL;Data Source=ИмяСервера;Initial Catalog=ИмяБазы;User ID=Логин;Password=Пароль;TrustServerCertificate=Yes;";

Обратите внимание на параметр TrustServerCertificate=Yes. В новом драйвере требования к безопасности повышены, и без явного указания доверия к сертификату сервера подключение к базам без SSL-сертификатов может завершиться ошибкой.

---

Резюме

Мы проанализировали проблему и выявили, что сбой подключения ADO в УТ 10 при успешной работе в БП 3 связан с тем, что в УТ 10 код по умолчанию выполняется на клиенте, разрядность платформы которого (32-бит) часто не совпадает с разрядностью установленного в ОС драйвера СУБД. Рекомендуется переносить подобные ресурсоемкие интеграции на сторону сервера 1С или использовать универсальный встроенный провайдер SQLOLEDB, не требующий дополнительной установки.