Каждый разработчик на платформе 1С:Предприятие рано или поздно сталкивается с мистической на первый взгляд ситуацией. Вы выполняете запрос в коде программы (например, в режиме отладки), и он возвращает пустой результат. Однако, когда вы копируете этот же самый текст запроса, устанавливаете те же параметры в консоли запросов и запускаете его — консоль возвращает ожидаемые строки данных.
В этой статье мы подробно разберем, почему возникает такое расхождение, рассмотрим внутренние механизмы платформы 1С и СУБД, которые к этому приводят, а также выработаем пошаговый алгоритм поиска и устранения этой проблемы.
Самая банальная и в то же время частая причина кроется в параметрах запроса. Нам часто кажется, что "пустое" значение — оно и в Африке пустое. Но для СУБД и платформы 1С пустая строка, значение Неопределено, значение NULL и пустая ссылка — это абсолютно разные типы данных с разным поведением.
Рассмотрим пример из практики. В запросе используется параметр &МаскаНомера:
Запрос.Текст =
"ВЫБРАТЬ
| БНФОНумераторСчетовАналитическогоУчета.Итератор
|ИЗ
| РегистрСведений.БНФОНумераторСчетовАналитическогоУчета КАК БНФОНумераторСчетовАналитическогоУчета
|ГДЕ
| БНФОНумераторСчетовАналитическогоУчета.МаскаНомера = &МаскаНомера";
В отладчике значение переменной выглядит как пустая строка "". Мы предполагаем, что передаем пустую строку. Однако в консоли запросов мы можем не указать тип параметра, и консоль по умолчанию передаст туда Неопределено или вообще исключит этот параметр из типизации, из-за чего СУБД построит совершенно другой план запроса или вернет иной результат сравнения.
Важно понимать: если в базе данных в поле МаскаНомера записано значение NULL (например, из-за особенностей левого соединения или ручного создания записей через СУБД), то прямое сравнение с пустой строкой МаскаНомера = "" вернет ложь. В то же время в консоли запросов мы можем случайно проверять условие иначе или неявно передавать другие типы пустых значений.
Чтобы избежать этой проблемы, всегда проверяйте точный тип параметров в отладчике. Для этого в табло отладчика вычисляйте выражение:
ТипЗнч(СтруктураВозврата.КлючНумератора.МаскаНомера)
Если вам необходимо корректно обрабатывать пустые строки и возможные значения NULL в запросе, используйте безопасную конструкцию в тексте запроса:
И (БНФОНумераторСчетовАналитическогоУчета.МаскаНомера = &МаскаНомера
ИЛИ БНФОНумераторСчетовАналитическогоУчета.МаскаНомера ПОДОБНО """")
Если ваш запрос выполняется внутри транзакции (например, при проведении документа, в обработчиках ПередЗаписью или ПриЗаписи модуля объекта/менеджера регистра), то состояние базы данных для этого сеанса будет существенно отличаться от того, что видит консоль запросов.
Разберем этот механизм подробнее:
Read Committed Snapshot Isolation (RCSI), внешние сеансы (ваша консоль) будут видеть старую ("снимковую") версию данных до тех пор, пока транзакция в коде не завершится успешным коммитом (фиксацией). Из-за этого в консоли вы видите данные, а внутри выполняющегося кода — нет.Проанализируйте стек вызовов в отладчике в момент остановки. Если вы находитесь внутри транзакции записи, помните, что физическая таблица в этот момент находится в промежуточном состоянии.
Механизм RLS (Row-Level Security) — один из самых частых виновников "исчезновения" данных из запросов в коде.
Представим ситуацию: вы вошли в систему под учетной записью администратора и открыли консоль запросов. Запрос отрабатывает отлично. В то же время отлаживаемый код запускается в контексте обычного пользователя, у которого настроены ограничения прав доступа (например, по организациям или физическим лицам).
Особенность работы RLS в 1С заключается в том, что платформа при нехватке прав доступа на чтение конкретных строк таблицы не выдает никаких ошибок или предупреждений. Она просто "тихо" отфильтровывает эти записи из результата запроса на уровне СУБД.
Выяснить, виновен ли RLS в пустом результате, очень просто. Достаточно временно обернуть выполнение запроса в коде в привилегированный режим, который полностью отключает проверку прав доступа:
УстановитьПривилегированныйРежим(Истина);
РезультатЗапроса = Запрос.Выполнить();
Выборка = РезультатЗапроса.Выбрать();
УстановитьПривилегированныйРежим(Ложь);
Если после включения привилегированного режима запрос в коде вернул данные — проблема однозначно в настройках прав доступа и шаблонах RLS для текущего пользователя.
Иногда визуальное совпадение параметров в консоли и в отладчике является обманчивым из-за существования дублирующихся элементов или повреждения ссылочной целостности базы данных.
СтруктураВозврата.КлючНумератора.Организация передается ссылка на другую (дублирующую) организацию. Визуально в отладчике вы увидите одно и то же название, но на уровне СУБД это будут два разных уникальных идентификатора (UUID)."<Объект не найден> (121:80e300155d03050711ebbcf38c117b38)". Если вы попытаетесь найти его в консоли, вы его просто не обнаружите или выберете другой элемент. Естественно, запрос по "битой" ссылке вернет пустой результат.Чтобы исключить эту причину, всегда проверяйте уникальные идентификаторы ссылочных параметров в коде и в консоли с помощью метода:
СсылкаНаОбъект.УникальныйИдентификатор()
Сравните полученные строки UUID. Они должны совпадать символ в символ.
Платформа 1С:Предприятие активно кэширует данные для оптимизации производительности. При работе с транзакциями кэш на сервере приложений может не успеть обновиться для текущего сеанса отладки.
Кроме того, если в системе установлены расширения конфигурации, они могут неявно модифицировать текст запроса или его параметры "на лету" через механизмы перехвата методов (аннотации &Перед, &Вместо, &После).
Попробуйте временно отключить расширения, которые могут влиять на логику работы данного регистра или справочника, а также выполнить очистку кэша сервера и клиентского приложения перед повторным тестированием.
Если вы столкнулись с разницей в результатах запроса, рекомендуем пройти по следующему алгоритму:
Запрос со всеми установленными параметрами и открыть его в консоли в том же контексте выполнения, что минимизирует влияние различий в окружении.