Как повысить производительность при работе 1С с Firebird через внешние источники данных (ODBC)?

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

В этой статье мы подробно разберем, почему возникает такая разница в производительности, проанализируем узкие места в связке 1С — ODBC — Firebird и рассмотрим конкретные шаги по оптимизации этой связки.

Выясняем причину: почему ODBC работает медленно?

Проанализируем ситуацию: когда 1С обращается к внешнему источнику, она взаимодействует не с самой базой напрямую, а через прослойку в виде ODBC-драйвера. Основная проблема часто кроется не в сложности SQL-запроса (планы запросов в Firebird обычно оптимальны), а в том, как данные передаются «по трубе» от сервера БД к платформе 1С.

Рассмотрим основные факторы, замедляющие работу:

1. Размер порции данных (Fetch Size): Если драйвер настроен на получение данных мелкими порциями, 1С вынуждена совершать тысячи микро-запросов к драйверу, что создает огромные накладные расходы.
2. Серверные курсоры: Платформа 1С активно использует курсоры для навигации по наборам данных. Бесплатные ODBC-драйверы Firebird могут эмулировать их крайне неэффективно.
3. Избыточность типов данных: Чтение полей типа BLOB или очень длинных VARCHAR заставляет систему выделять значительные ресурсы памяти на каждую строку.

Шаг 1. Настройка параметров ODBC-драйвера

Первым делом нам необходимо заглянуть в настройки DSN (Data Source Name) на сервере, где исполняется код 1С. В настройках ODBC-драйвера для Firebird есть параметры, отвечающие за буферизацию данных.

Разберем, что нужно проверить:

• Найдите параметр Fetch или Fetch Size. Увеличьте его значение (например, до 1000 или 5000). Это позволит драйверу забирать данные у сервера Firebird крупными блоками.
• Проверьте использование клиентских курсоров. Иногда переключение режима курсора в настройках драйвера (например, использование Static или Forward Only) дает существенный прирост в 1С.

Шаг 2. Использование SQL-представлений (View) вместо прямых таблиц

Одной из лучших практик при работе с ВИД является отказ от прямого подключения таблиц БД. Вместо этого мы создадим в Firebird Представления (VIEW) и подключим их в 1С как таблицы внешнего источника.

Почему это помогает? Рассмотрим на примере:

-- В базе Firebird создаем представление
CREATE VIEW V_STOCK_REMAINS AS
SELECT 
    ID, 
    CAST(ARTICLE AS VARCHAR(50)) AS ARTICLE, 
    QUANTITY 
FROM REAL_BIG_TABLE
WHERE IS_ACTIVE = 1;

Использование CAST позволяет нам жестко ограничить длину строковых полей. Если в Firebird поле определено как VARCHAR(8000), 1С зарезервирует под него максимум памяти. Приведение к VARCHAR(50) через View значительно ускорит передачу данных.

Шаг 3. Обработка данных в 1С: Порционный метод

Если нам необходимо загрузить большой объем данных (например, 43 000 строк для первоначального заполнения справочника), не стоит пытаться прочитать всё одним запросом через ВнешниеИсточникиДанных.Таблица.Выбрать(). Разберем, как реализовать порционное чтение.

Проанализируем пример кода для эффективного чтения:

Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	ВнешнийИсточник.ID КАК ID,
    |	ВнешнийИсточник.Наименование КАК Наименование
    |ИЗ
    |	ВнешнийИсточникДанных.FirebirdBase.Таблицы.СправочникТоваров КАК ВнешнийИсточник
    |ГДЕ
    |	ВнешнийИсточник.ID > &ПоследнийID
    |УПОРЯДОЧИТЬ ПО
    |	ID";

Запрос.УстановитьПараметр("ПоследнийID", 0);
Пока Истина Цикл
    Результат = Запрос.Выполнить().Выгрузить();
    Если Результат.Количество() = 0 Тогда
        Прервать;
    КонецЕсли;
    
    // Обработка порции данных
    Для каждого Строка Из Результат Цикл
        // ... логика загрузки ...
        Запрос.УстановитьПараметр("ПоследнийID", Строка.ID);
    КонецЦикла;
КонецЦикла;

Такой подход позволяет 1С запрашивать данные небольшими пакетами, что предотвращает "подвисание" сеанса и переполнение буфера ODBC-драйвера.

Шаг 4. Настройка кодировок (Charset)

Несоответствие кодировок — скрытый убийца производительности. Если база Firebird создана в WIN1251, а драйвер в строке подключения пытается использовать UTF8, то на каждой строке будет происходить перекодировка.

Проанализируем строку подключения. Убедитесь, что параметр CharacterSet соответствует кодировке вашей базы:

DRIVER={Firebird/InterBase(r) driver};User=SYSDBA;Password=masterkey;Database=localhost:C:\DB\MYBASE.FDB;CharacterSet=WIN1251;

Шаг 5. Оптимизация работы с Динамическими списками

Если вы выводите данные из Firebird напрямую в форму 1С через Динамический список, платформа по умолчанию пытается выполнить команду SELECT COUNT(*). В Firebird из-за особенностей многоверсионности (MVCC) подсчет строк в большой таблице всегда требует полного сканирования (Full Table Scan).

Рассмотрим решение: в настройках динамического списка на форме установите свойство "Использовать основную таблицу", но при этом в настройках самого списка (закладка "Настройка списка") в конфигураторе отключите автоматический подсчет количества записей (установите режим "Не рассчитывать").

Использование альтернативных провайдеров

Если стандартный бесплатный ODBC-драйвер продолжает показывать низкие результаты, стоит рассмотреть использование OLE DB Provider (например, IBProvider). В отличие от ODBC, специализированные OLE DB провайдеры лучше оптимизированы под логику навигации 1С и умеют более эффективно работать с типами данных Firebird.

Подведем итог: для быстрой работы 1С и Firebird через внешние источники данных мы должны минимизировать количество передаваемых данных с помощью VIEW, настроить Fetch Size в драйвере и следить за соответствием кодировок. Для разовых массовых загрузок всегда используйте порционное чтение с отбором по индексированным полям.