Просто предположение, потому что вы не объяснили, что или как запрос не выполняется, но, на мой взгляд, это условие не выглядит правильным:
request.date <= '2019-01-10'
Распространенной ошибкой является ожидание, что подобное условие при использовании части диапазона включает все записи, где часть даты в поле даты и времени равна 2019-01-10
. То есть, если у нас есть пример значения в базе данных на 13:00 в тот же день (2019-01-10 13:00:00
), ожидается, что это значение будет сужаться, чтобы соответствовать литералу 2019-01-10
в запросе, эти два значения будут равны, и так будет соответствовать условию.
Так работает.
Вместо этого литерал 2019-01-10
в запросе расширен до полного DateTime, который выглядит примерно так: 2019-01-10 00:00:00.000
. Теперь значение 13:00 из таблицы сравнивается с этим временем полной даты, и оно не соответствует условию.
Гораздо чаще для диапазона дат сравнивать, используя исключительную верхнюю границу, установленную для одного дня в будущем:
request.date < '2019-01-11'
Кроме того, у вас может возникнуть соблазн сделать это:
request.date <= '2019-01-10 23:59:59.999'
Это будет работать даже большую часть времени. Просто имейте в виду, что в (редких) случаях високосных секунд вы все равно можете получить неправильные результаты таким образом.
Вы также можете испытать желание сделать что-то вроде этого:
convert(date,request.date) <= '2019-01-10'
Это работает, но не рекомендуется, потому что предотвращает использование любого индекса, который может быть у вас в поле request.date
, и это снижает производительность базы данных.
Или, может быть, проблема еще проще. С началом диапазона в 2019-01-09
, возможно, вы хотели получить записи ровно за один день, и удивились, увидев несколько значений с полуночи 2010-01-10
. Опять же, решение заключается в том, что вы хотите исключительную границу в верхней части диапазона:
request.date < '2019-01-10'
Как полное примечание к вопросу, мне очень грустно, что оператор SQL BETWEEN
включен в обоих концах диапазона. Это может иметь смысл для числовых или строковых данных, но для значений даты, определяющих исключительную верхнюю границу для оператора BETWEEN
, имело бы гораздо больший смысл.