Если print_date
является datetime
, а не только date
, вам нужно будет принять во внимание элемент time
. Под этим я подразумеваю, что 2017-01-20 13:48:00
фактически не равен 2017-01-20
, потому что SQL Server скрытно добавляет время 00:00:00
, и два больше не совпадают.
Для борьбы с этим, вы можете конвертировать ваше datetime
значения в date
или все в то же самое время, но это снижает способность оптимизатора запросов, чтобы сделать ваш запрос более эффективным, так как должно быть прочитано и превращали каждое значение , а затем по сравнению.
Вместо того, чтобы не замедлить ваш Оптимизатор вам нужно сохранить то, что известно как SARGability и просто сделать сравнение datetime
значений других datetime
значений:
declare @sdate date -- Remember that date types add 00:00:00 when compared to datetime.
set @sdate ='20172001' -- Make this the date you want values for.
declare @edate date
set @edate ='20172002' -- Make this the day *after* the date you want values for.
-- To save changing two values, you could just calculate
-- this value using dateadd(d,1,@sdate).
select i.print_date
from dbo.WC_view_bill_hdr as i
join dbo.WC_view_customer as c
on i.customer_id = c.customer_id
join WC_view_bill_batch as ib
on ib.bill_batch_uid = c.bill_batch_uid
where i.print_date >= @sdate -- All values from the very start of this date.
and i.print_date < @edate; -- but that are less than the day after.
Если вы делаете ваши сравнения дат таким образом , SQL Server может обеспечить наиболее эффективное использование любых индексов у вас на столах, а также добавить степень будущего цветопробы для более точных datetime
значений:
Например, datetime
только с точностью до 3 мс, так что ухо (2017-01-21
) будет 2017-01-20 23:59:59:997
. Если вы установили свой запрос в between '2017-01-20 00:00:00.000' and '2017-01-20 23:59:59:997'
, то есть 3 миллисекунды пробела, который еще не проблема.
Однако, если вы переехали в datetime2
, которые могут представляют значения больше, чем 997 миллисекунд, то теперь явно ошибочно исключая значения, которые вы не должны быть.
Это бесконечная проблема, поскольку для «конца сегодняшнего дня» нет ценности для «начала завтра», которая не может быть далее разделена на бесконечность.
Но просто указав Greater than or equal to the start of today
и less than the start of tomorrow
, вам гарантировано получить все.
Если вам нужен только один день данных, вы должны установить дату окончания диапазона так же, как и дату начала. –
Зачем даже устанавливать диапазон. Просто «i.print_date = @ sdate» –
Я знаю, что вы говорите, я пытался это сделать, но ничего не возвращает.Я добавил параметр в отчет, чтобы я мог видеть, как он заполняется, и он показал «1/20/17 12:00:00 AM» в качестве значения. Я могу сделать это по типу вещей в студии sql, и он работает «order_date BETWEEN '09/30/16 00: 00: 00: 000 'AND '09/30/16 23: 59: 59: 999'", но не уверен как перевести это в SSRS – cspell