Запрос с отбором по реквизиту, который может быть не указан
Мучаюсь с запросом.
ДатаНачала и ДатаОкончание могут не заполняться. Если не заполнены, значит проверять не нужно.
Можно ли такое вообще реализовать?
"ВЫБРАТЬ
| АдрПомещения_ФизЛица.ФизическоеЛицо КАК ФизическоеЛицо,
|ИЗ
| Справочник.АдрПомещения_ФизЛица КАК АдрПомещения_ФизЛица
|
|ГДЕ
|АдрПомещения_ФизЛица.ДатаНачала <= &ДатаЗапросаКонецМесяцаДата
|И АдрПомещения_ФизЛица.ДатаОкончание >= &ДатаЗапросаНачалоМесяцаДата
|
... ПоказатьДатаНачала и ДатаОкончание могут не заполняться. Если не заполнены, значит проверять не нужно.
Можно ли такое вообще реализовать?
По теме из базы знаний
- Быстрый поиск дублей в 1С с четким/нечетким поиском по любому сочетанию реквизитов/реквизитов таб. частей с отбором и быстрой заменой значений в ЛЮБЫХ базах 8.1-8.3 (УТ 10.3, БП 2, ЗУП 2.5, КА 1.1, УТ 11, БП 3, УНФ 1.6/3.0, КА 2, ЗУП 3 и т.д.)
- Конфигурация Flowcon: Набор инструментов для управления задачами, проектами и бизнесом в 1С
- Строковые отборы в 1С
- Смотрим запросы 1С через Microsoft SQL Profiler по следам ошибок разработчиков, приводящих к проблемам производительности
- Несколько альтернативных универсальных способов подбора ссылок при переносах данных
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
ГДЕ
ВЫБОР
КОГДА АдрПомещения_ФизЛица.ДатаНачала = ДАТАВРЕМЯ(1,1,1)
ТОГДА АдрПомещения_ФизЛица.ДатаНачала <= &ДатаЗапросаКонецМесяцаДата
ИНАЧЕ ИСТИНА
КОНЕЦ И ВЫБОР
КОГДА АдрПомещения_ФизЛица.ДатаОкончание = ДАТАВРЕМЯ(1,1,1)
ТОГДА АдрПомещения_ФизЛица.ДатаОкончание >= &ДатаЗапросаНачалоМесяцаДата
ИНАЧЕ ИСТИНА
КОНЕЦ Показать|ГДЕ
|(АдрПомещения_ФизЛица.ДатаНачала <= &ДатаЗапросаКонецМесяцаДата ИЛИ &ДатаЗапросаКонецМесяцаДата = ДАТАВРЕМЯ(1,1,1))
|И (АдрПомещения_ФизЛица.ДатаОкончание >= &ДатаЗапросаНачалоМесяцаДата ИЛИ &ДатаЗапросаНачалоМесяцаДата = ДАТАВРЕМЯ(1,1,1))
(9) Лет пять назад меня тут же по этому поводу поправляли. К сожалению, не могу найти и статью о медленной работе CASE по сравнению с "прямым" сравнением, не гуглится что-то.
Но можно почитать эту статью - .
Там нет подтверждения моим словам полностью, но по крайней мере показывает несостоятельность примера предложенного в (3).
Но можно почитать эту статью - .
Там нет подтверждения моим словам полностью, но по крайней мере показывает несостоятельность примера предложенного в (3).
Сделал так:
|ГДЕ
|
|(АдрПомещения_ФизЛица.ДатаНачала <= &ДатаЗапросаКонецМесяцаДата ИЛИ АдрПомещения_ФизЛица.ДатаНачала = ДАТАВРЕМЯ(1,1,1))
|И (АдрПомещения_ФизЛица.ДатаОкончание >= &ДатаЗапросаКонецМесяцаДата ИЛИ АдрПомещения_ФизЛица.ДатаОкончание = ДАТАВРЕМЯ(1,1,1))
|И (АдрПомещения_ФизЛица.ФизическоеЛицо.ДатаСмерти > &ДатаЗапросаКонецМесяцаДата ИЛИ АдрПомещения_ФизЛица.ФизическоеЛицо.ДатаСмерти = ДАТАВРЕМЯ(1,1,1))
(13) Динамической сборки текста запроса нужно, по возможности, избегать. Это затрудняет анализ кода/текста запроса. Когда-то вроде встречал это и в рекомендациях от 1С.
По условиям в СКД поддерживаю.
Если попытаться ещё оптимизировать, то в запросе из (12) можно заменить ДАТАВРЕМЯ(1,1,1) на параметр с пустой датой, чтобы не тратилось время на формирование даты при выполнении самого запроса. (Хотя там должна вроде как срабатывать оптимизация, но один раз, как миниум, datetime будет выполнено.)
По условиям в СКД поддерживаю.
Если попытаться ещё оптимизировать, то в запросе из (12) можно заменить ДАТАВРЕМЯ(1,1,1) на параметр с пустой датой, чтобы не тратилось время на формирование даты при выполнении самого запроса. (Хотя там должна вроде как срабатывать оптимизация, но один раз, как миниум, datetime будет выполнено.)
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот