Как связать 1С и SQL: рабочие способы интеграции

Связка 1С и SQL нужна в двух принципиально разных сценариях. Первый — перевести информационную базу из файлового режима в клиент-серверный, где данные хранятся в СУБД (MS SQL Server, PostgreSQL, Oracle, IBM DB2). Второй — наладить обмен между уже работающей 1С и отдельной SQL-базой: например, выгружать остатки на сайт или забирать заказы из внешней системы.

Эти задачи решаются разными инструментами, и путать их нельзя. Клиент-серверный режим — штатная архитектура, которую платформа поддерживает официально. Обмен с внешней базой — это интеграция, которую вы проектируете и сопровождаете самостоятельно. Ниже разобраны оба направления с конкретными шагами настройки.

Отдельное предупреждение касается «прямых» запросов к таблицам базы 1С. Структура таблиц, которую платформа создаёт в СУБД, внутренняя: имена полей вида _Fld123, служебные разделители, хранение дат и ссылок в особом формате. Писать в такие таблицы напрямую категорически нельзя — это гарантированное повреждение данных и потеря поддержки.

Выбор способа связи: что подходит под вашу задачу

Прежде чем настраивать, определите, какая из задач стоит перед вами. От этого зависит весь дальнейший план работ и набор инструментов.

Если цель — ускорить работу пользователей и обеспечить параллельный доступ, выбирайте клиент-серверный режим. Если нужно обмениваться данными с сайтом, CRM или складской системой — стройте интеграцию через ADO, внешние источники данных или промежуточные таблицы. Если задача — аналитика и отчёты поверх данных 1С, достаточно чтения реплики базы.

Клиент-серверный режим: база 1С на MS SQL Server

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

Порядок действий такой. Сначала установите MS SQL Server поддерживаемой версии (соответствие версий проверяйте в системных требованиях платформы — не всякая связка «платформа + СУБД» поддерживается). Затем установите сервер 1С:Предприятия, создайте пустую базу в SQL Server и зарегистрируйте информационную базу в консоли кластера, указав сервер СУБД, имя базы и учётные данные. После этого загрузите в неё данные через конфигуратор из файловой копии (режим «Загрузить информационную базу»).

1. 1
   Сделайте выгрузку файловой базы через конфигуратор (.dt) — это ваша страховка
2. 2
   Установите MS SQL Server и проверьте, что служба запущена и доступна по сети
3. 3
   Установите сервер 1С:Предприятия той же разрядности, что требует ваше окружение
4. 4
   Создайте пустую базу в SQL Server с collation Cyrillic_General_CI_AS
5. 5
   Зарегистрируйте базу в консоли кластера серверов 1С с указанием СУБД и учётных данных
6. 6
   Откройте конфигуратор новой базы и загрузите данные из .dt
7. 7
   Проверьте вход пользователей и выполните тестирование и исправление при необходимости

Критичный момент — параметр сортировки (collation) базы. Для русскоязычных баз 1С требуется Cyrillic_General_CI_AS. Если создать базу с другим collation, платформа откажется с ней работать или будет вести себя некорректно при сравнении строк, и исправить это без пересоздания базы нельзя.

Клиент-серверный режим на PostgreSQL

PostgreSQL — популярная альтернатива MS SQL, особенно когда важно снизить стоимость лицензий на СУБД. Для работы с 1С используется специальная сборка PostgreSQL с патчами от вендора платформы или совместимые дистрибутивы — «ванильный» PostgreSQL из официального репозитория платформа не поддерживает.

Общая логика настройки совпадает с MS SQL: ставите СУБД, сервер 1С, создаёте базу и регистрируете её в кластере. Различия — в тонкостях конфигурации: PostgreSQL требует ручной настройки памяти (shared_buffers, work_mem) и параметров подключений, иначе производительность на больших базах будет заметно ниже потенциальной.

Обращение из 1С к внешней SQL-базе через ADO

Когда нужно, чтобы 1С читала или писала данные в отдельную SQL-базу (не свою собственную), классический способ — COM-объект ADODB.Connection. Он доступен на Windows и позволяет выполнять произвольные запросы из встроенного языка.

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

Соединение = Новый COMОбъект("ADODB.Connection");
СтрокаПодключения = "Provider=SQLOLEDB;Data Source=SQLSERVER;Initial Catalog=Exchange;Integrated Security=SSPI";
Соединение.Open(СтрокаПодключения);
Набор = Соединение.Execute("SELECT Id, Name FROM dbo.Goods");
Пока НЕ Набор.EOF Цикл
    Сообщить(Набор.Fields("Name").Value);
    Набор.MoveNext();
КонецЦикла;
Соединение.Close();

Два практических ограничения. Во-первых, COM работает только там, где установлен соответствующий OLE DB/ODBC-провайдер, и код должен выполняться на стороне, где он доступен — обычно это сервер 1С или толстый клиент на Windows. Во-вторых, при ошибках в запросе исключения COM всплывают в 1С в малочитаемом виде, поэтому оборачивайте вызовы в попытку/исключение и логируйте текст запроса.

Внешние источники данных как альтернатива

Механизм внешних источников данных позволяет подключить таблицы внешней базы через ODBC и использовать их в запросах и отчётах 1С почти как штатные объекты. Это удобно для отчётности: не нужно писать код обхода записей, данные доступны в конструкторе запросов. Платой является производительность и необходимость настроить ODBC-источник на каждом рабочем месте или сервере.

Чтение данных 1С из внешних систем

Обратная задача — когда внешней системе (сайту, Power BI, скрипту на Python) нужны данные из базы 1С. Прямое чтение таблиц возможно, но требует понимания внутренней структуры: имена таблиц и полей генерируются платформой (_Reference123, _Fld456), ссылки хранятся как бинарные значения, а итоги регистров — в отдельных таблицах итогов.

Более надёжные альтернативы: публикация HTTP-сервисов или OData-интерфейса средствами платформы (стандартный OData даёт доступ к объектам конфигурации через REST-подобный протокол), либо регламентная выгрузка нужных данных в промежуточную SQL-базу с понятной структурой. Второй вариант особенно хорош для аналитики: внешние инструменты работают с нормальными именами таблиц и не зависят от внутренностей платформы.

Безопасность и учётные данные

Любая связка 1С и SQL упирается в вопрос доступа. Для клиент-серверного режима создайте в СУБД отдельную учётную запись для сервера 1С с правами только на базы 1С — не используйте sa или postgres. Для интеграций через ADO заведите пользователя с минимально необходимыми правами: если 1С только читает справочник товаров, прав на запись ей не нужно.

Строки подключения с паролями не храните в открытом виде в коде общих модулей — они попадают в выгрузки конфигурации и репозитории. Используйте защищённые хранилища, параметры сеанса или хотя бы отдельный модуль с ограниченным доступом. Для Windows-аутентификации (Integrated Security) пароль в строке подключения вообще не нужен, что снижает риск утечки.

Проверка результата и диагностика проблем

После настройки клиент-серверного режима проверьте три вещи: база открывается в конфигураторе и предприятии, в SQL Server Management Studio видны таблицы с данными, а пользователи могут работать одновременно без конфликтов блокировок. Дополнительно полезно запустить типовую операцию (проведение документа) и убедиться, что время отклика приемлемое.

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

Часто задаваемые вопросы