有人可以告诉我为什么我的数据库选择查询要求订单
WHERE [order].dateplaced >= DATEADD(millisecond,-3,ISNULL(@datefrom, @searchscope))
AND [order].dateplaced < DATEADD(millisecond,-3,DATEADD(day,1,ISNULL(@dateto, GETDATE())))
当@datefrom和@dateto都设置在同一个日期时,在@dateto午夜前三分半钟内错过了一个订单?
我已尝试更改查询,因此初始DATEADD会在两个日期时间中添加一秒,而不是从两者中删除3毫秒,并且它仍然不会拉顺序。
作为参考,日期的确切日期时间为:2009-01-20 23:56:17.933
我愚蠢吗?
编辑:我现在记得为什么三毫秒的事情发挥作用。这是因为我们的帐户工作整整几个月,如果你想要一个月的报告,你可以设置它,例如,从01年1月1日到2月1日,这将包括截至2月1日午夜的一切。(顺便说一下独家或包容?)然而,人们太愚蠢到实际设置日期范围,他们将设置它从1月1日至1月31日,错过一天(不要问我)。由于我知道SQL Server的工作分辨率为3毫秒,所以我首先请求31-Jan,直到11月31日59:59.997,而01 - 2月仍然会从午夜开始。然而,为了补偿那个“从”的日期,我不得不放下三毫秒,所以没有任何东西可以穿过裂缝。我只是假设SQL Server能够处理它。现在可能会遗漏这些报告中的一些内容,所以我必须去查看这些内容。
虽然下面的最高投票解决方案适用于所有实际目的(我们银行的信用卡结算软件仍然会在午夜的任何一方随机地将交易放在“错误”方面,就我们的系统而言)它仍然没有回答为什么具有良好的三分半钟优惠的交易未能被捕获的问题。我很欣赏只是浪费时间会在大部分时间工作,但我们业务的性质意味着在某些日期我们有大约20分钟的实际时间段,其中更高的分辨率和精确处理将是方便的。
对于好奇的我们在英国出售音乐会门票,例如,我们有阅读或V节开始销售的日子,我们在售后20分钟内转移了几千张门票,剩下的其他东西的销售额正常。那些二十分钟的时期成为大量报道和解剖的目标,因为负载均衡器并不总是完美的,并且会出现奇怪的记录故障。因此能够将记录切割成几秒钟将是很方便的。我对软件的信心有点动摇,所以一个实际的答案会很方便。
然而,就目前而言,我正在做的特别事情对于下面的最高投票解决方案是好的...
答案 0 :(得分:1)
GETDATE()有a time portion which you are not trimming off(你可能也希望减去其他变量的时间部分)。我不知道你为什么要用毫秒来搞乱。我知道3毫秒是最小的分辨率,但我通常不必使用它来处理范围端点。
DECLARE @today AS DATETIME
SET @today = DATEADD(dd, 0, DATEDIFF(dd, 0, GETDATE()))
SET @datefrom = DATEADD(dd, 0, DATEDIFF(dd, 0, @datefrom))
SET @searchscope = DATEADD(dd, 0, DATEDIFF(dd, 0, @searchscope))
SET @dateto = DATEADD(dd, 0, DATEDIFF(dd, 0, @dateto))
SELECT *
FROM [order]
WHERE [order].dateplaced >= ISNULL(@datefrom, @searchscope)
AND [order].dateplaced < DATEADD(day, 1, ISNULL(@dateto, @today))
答案 1 :(得分:1)
这适用于SQL 2000和2008:
declare @datefrom datetime
declare @dateto datetime
set @datefrom='2009-01-20'
set @dateto='2009-01-20'
select case when '2009-01-20 23:56:17.933' >= DATEADD(millisecond,-3,@datefrom) then '>=' else 'NOT >=' end
select case when '2009-01-20 23:56:17.933' < DATEADD(millisecond,-3,DATEADD(day,1,@dateto)) then '<' else 'NOT <' end
问题可能比你告诉我们的还要多。