Почему запрос 1С работает в консоли, но не находит данные в программном коде

← На главную

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

Разбор исходной ситуации

Рассмотрим типичный фрагмент кода, который часто становится источником проблем. Разработчик пытается найти документ НачислениеЗарплаты по конкретному сотруднику и дате:


Запрос = Новый Запрос;
Запрос.Текст = 
    "ВЫБРАТЬ
    |	НачислениеЗарплаты.Ссылка КАК Ссылка
    |ИЗ
    |	Документ.НачислениеЗарплаты КАК НачислениеЗарплаты
    |ГДЕ
    |	НачислениеЗарплаты.Сотрудник = &Сотрудник
    |	И НачислениеЗарплаты.Дата = &Дата";

Запрос.УстановитьПараметр("Сотрудник", Справочники.Сотрудники.НайтиПоНаименованию(Сотрудник));
Запрос.УстановитьПараметр("Дата", ДатаДокумента);

Результат = Запрос.Выполнить().Выгрузить();

На первый взгляд код выглядит логично, но именно здесь кроются "подводные камни", связанные с типизацией и особенностями работы платформы 1С:Предприятие.

Проблема №1: Несоответствие типов данных

Это самая распространенная причина. В 1С тип Дата — это не просто строка с цифрами, а специальный объект. Если в переменную ДатаДокумента попало строковое представление (например, из текстового файла, Excel или элемента формы без привязки к типу), то запрос не выдаст ошибку. Система просто попытается сравнить поле типа Дата в таблице базы данных со значением типа Строка. Поскольку типы разные, совпадений найдено не будет.

Как проверить: Воспользуемся отладчиком. Необходимо вычислить выражение ТипЗнч(ДатаДокумента). Если результат Строка, необходимо преобразовать её в дату с помощью функции Дата() или убедиться, что источник данных типизирован верно.

Аналогичная проблема часто возникает и с параметром Сотрудник. Рассмотрим конструкцию Справочники.Сотрудники.НайтиПоНаименованию(Сотрудник). Если переменная Сотрудник сама по себе уже является ссылкой на элемент справочника, то повторный поиск по наименованию от ссылки может вернуть Неопределено или пустую ссылку, так как метод ожидает строку.

Проблема №2: Коварство метода НайтиПоНаименованию

Давайте проанализируем, почему использование НайтиПоНаименованию в запросах — это плохая практика:

Дубликаты: Если в справочнике есть два сотрудника с одинаковыми ФИО (например, полные тезки), метод вернет ссылку на того, кто был создан раньше или выше по иерархии. В консоли вы могли выбрать "правильного" сотрудника вручную, а код нашел "неправильного".
Невидимые символы: Пробелы в конце строки, неразрывные пробелы или разница в регистрах могут привести к тому, что НайтиПоНаименованию вернет Справочники.Сотрудники.ПустаяСсылка(). Запрос выполнится, но будет искать документы, где поле сотрудник не заполнено.
Лишняя нагрузка: Выполнение поиска ссылки перед запросом — это лишнее обращение к базе. Если есть возможность, лучше передавать в параметры готовую ссылку или искать по коду/УИД.

Проблема №3: Точность даты до секунды

В 1С тип Дата всегда содержит время. Когда мы пишем условие НачислениеЗарплаты.Дата = &Дата, происходит сравнение с точностью до секунды. Если в базе документ записан в 12:00:01, а в параметр передано значение 12:00:00, документ найден не будет.

Для решения этой проблемы рекомендуется использовать границы периода. Рассмотрим, как переписать условие поиска по дате более надежно:


// Вместо строгого равенства используем начало и конец дня
Запрос.Текст = 
    "ВЫБРАТЬ ... ГДЕ Дата МЕЖДУ &НачалоДня И &КонецДня";
Запрос.УстановитьПараметр("НачалоДня", НачалоДня(ДатаДокумента));
Запрос.УстановитьПараметр("КонецДня", КонецДня(ДатаДокумента));

Проблема №4: Ограничение доступа на уровне записей (RLS)

Выясним еще одну важную причину. Консоль запросов часто запускается под пользователем с полными правами. В этом случае система игнорирует настройки RLS. Однако программный код может выполняться в контексте пользователя с ограниченными правами.

Если у пользователя нет прав на чтение конкретных записей в справочнике Сотрудники или на чтение документов НачислениеЗарплаты, запрос просто вернет пустой результат. Платформа не выдаст ошибку "Доступ запрещен", она просто "скроет" записи от запроса.

Решение: Проверьте выполнение кода под пользователем с ролью ПолныеПрава или временно используйте режим УстановитьПривилегированныйРежим(Истина), чтобы исключить влияние RLS при отладке.

Алгоритм отладки "неработающего" запроса

Если запрос в коде не находит данные, рекомендуем пройти по следующим шагам:

Проверка параметров через отладчик: Остановите выполнение кода перед Запрос.Выполнить(). В окне "Табло" проверьте каждое значение, которое вы передаете в УстановитьПараметр. Особое внимание уделите типам (используйте ТипЗнч(...)).
Проверка на пустую ссылку: Убедитесь, что методы поиска (НайтиПоНаименованию, НайтиПоКоду) действительно вернули объект, а не ПустаяСсылка.
Сравнение ГУИД: Если вы уверены, что ссылка верная, сравните её уникальный идентификатор со ссылкой в консоли. Для этого используйте метод Ссылка.УникальныйИдентификатор().
Использование консоли внутри кода: В современных инструментах разработчика есть возможность вызвать консоль запросов прямо из точки останова, передав в неё текущий запрос со всеми установленными параметрами. Это лучший способ увидеть, что именно "видит" запрос в данный момент.

Подводя итог, можно сказать, что в 90% случаев проблема кроется в типе данных. 1С — строго типизированная система, и строка "01.01.2023" никогда не будет равна дате 01.01.2023 00:00:00. Будьте внимательны при передаче параметров и всегда проверяйте их реальное содержимое в режиме отладки.