Почему запрос к внешнему источнику данных (Firebird) возвращает пустой результат на сервере 1С, но работает в консоли?

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

Анализ программного формирования СКД

Первым делом проанализируем ситуацию, когда данные не попадают в результат при программном выводе схемы компоновки данных. Часто ошибка кроется в том, как именно передаются параметры в настройки. В сообщении форума автор использовал прямое обращение к коллекции параметров схемы, что не всегда корректно отрабатывает при компоновке макета. Разберем правильный подход к инициализации параметров через настройки компоновщика.

Посмотрим на пример кода, который гарантирует правильную передачу параметров ДатаНачала и ДатаОкончания в запрос внешнего источника:

// Получаем настройки по умолчанию
Настройки = СхемаКомпоновкиДанных.НастройкиПоУмолчанию;

// Установка параметров через НастройкиДанных
ПараметрДатаНачала = Настройки.ПараметрыДанных.НайтиЗначениеПараметра(Новый ПараметрКомпоновкиДанных("ДатаНачала"));
Если ПараметрДатаНачала <> Неопределено Тогда
    ПараметрДатаНачала.Использование = Истина;
    ПараметрДатаНачала.Значение = ДатаНачала;
КонецЕсли;

ПараметрДатаОкончания = Настройки.ПараметрыДанных.НайтиЗначениеПараметра(Новый ПараметрКомпоновкиДанных("ДатаОкончания"));
Если ПараметрДатаОкончания <> Неопределено Тогда
    ПараметрДатаОкончания.Использование = Истина;
    ПараметрДатаОкончания.Значение = ДатаОкончания;
КонецЕсли;

Использование метода НайтиЗначениеПараметра позволяет работать непосредственно с объектом настроек, которые будут переданы в КомпоновщикМакета. Это критично, так как внешние источники данных крайне чувствительны к типизации параметров в блоке ГДЕ.

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

Выясним причину, по которой «в консоли работает, а на сервере нет». Это классическая проблема разрядности приложений. Консоль запросов часто запускается в тонком клиенте (32-битном), который использует 32-битную версию драйвера ODBC, настроенную в системе. Однако сервер 1С:Предприятие в большинстве случаев является 64-битным приложением.

Проанализируем шаги по диагностике этой проблемы:

1. Проверьте, установлен ли на сервере 64-битный драйвер Firebird ODBC.
2. Убедитесь, что System DSN настроен именно через 64-битную утилиту администрирования ODBC (находится в C:\Windows\System32\odbcad32.exe), а не через 32-битную (из SysWOW64).
3. Если на сервере настроен только пользовательский DSN (User DSN), сервер 1С, работающий под системной учетной записью, его просто «не увидит».

Права доступа технической учетной записи

Рассмотрим ситуацию с точки зрения системного администрирования. Когда вы запускаете консоль под своим логином, 1С обращается к внешней базе, используя ваши права доступа. Сервер 1С обычно работает под специальной учетной записью (например, USR1CV8).

Если у этой учетной записи нет прав на чтение папки с драйвером Firebird или клиентской библиотекой fbclient.dll, вызов внешнего источника может закончиться «молчаливым» возвратом пустой таблицы без генерации исключения. Проверьте права на чтение для папки с установленным клиентом Firebird для пользователя, под которым запущена служба 1C:Enterprise 8.3 Server Agent.

Особенности трансляции типов данных и кодировок

Firebird — СУБД, чувствительная к настройкам соединения. Рассмотрим наиболее важные параметры, которые могут влиять на результат фильтрации:

Кодировка (Character Set): Если в строке подключения (или настройках DSN) на сервере не указана кодировка (например, WIN1251), строковые параметры фильтров (названия филиалов, типов документов) могут передаваться в некорректном виде. В итоге условие WHERE не находит совпадений, и база возвращает пустой набор данных.

Формат даты: В запросе СКД используется конструкция МЕЖДУ &ДатаНачала И &ДатаОкончания. При выполнении на сервере платформа 1С транслирует эти даты в SQL-запрос. Если региональные настройки сервера 1С и сервера Firebird различаются, формат даты может быть интерпретирован неверно. Попробуйте протестировать запрос без фильтра по датам, чтобы исключить эту вероятность.

Чувствительность к регистру и Dialect 3

Проанализируем структуру запроса. В Firebird имена таблиц и полей, созданные без кавычек, хранятся в верхнем регистре. Если в 1С объект внешнего источника настроен с использованием кавычек или специфического регистра, драйвер может по-разному интерпретировать имена при серверном вызове.

В тексте запроса автора мы видим обращения типа DOCHEAD.ID_DOCHEAD. Убедитесь, что в метаданных внешнего источника в 1С имена таблиц точно соответствуют именам в схеме базы Firebird. Иногда полезно в настройках ODBC включить опцию "Quoted Identifiers", чтобы платформа 1С могла корректно обрамлять имена объектов кавычками при трансляции запроса.

Итоговый чек-лист для решения проблемы

Если вы столкнулись с пустым результатом запроса к ВИД на сервере, выполните следующие действия:

1. Проверьте настройки ODBC на сервере: Убедитесь, что используется System DSN и разрядность драйвера совпадает с разрядностью сервера 1С.
2. Сравните параметры подключения: Настройки драйвера на клиентской машине и на сервере должны быть идентичны (кодировка, версия клиентской библиотеки).
3. Упростите запрос для теста: Уберите все параметры ГДЕ и отборы СКД. Если данные появились — проблема в передаче параметров или типизации дат/строк.
4. Проверьте версию fbclient.dll: На сервере 1С должна быть установлена библиотека той же версии (или выше), что и сервер Firebird.
5. Программная инициализация: Используйте установку параметров через КомпоновщикНастроек.Настройки.ПараметрыДанных, как было показано в примере выше.

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