我正在运行VBA查询，该查询返回超过结束日期的数据。
代码如下：
$if enddate = 31/08/2016 结果显示截至02/09/2016（结束日期后两天）
答案 0 :(得分：0)
您的日期格式是问题所在：
startdate = Format(Sheets("sheet1").Range("B2").Value, "####")
enddate = Format(Sheets("sheet1").Range("B3").Value, "####")
这些将生成日期连续出版物，或自1900年1月1日以来经过的天数。对于2016年8月31日（2016年8月31日美国境内的人），您的{{使用Excel时，1}}将为42613。
在SQL Server中，您可以使用enddate或DATEADD(DAY, ..., ...)将其转换为日期。隐含地，当您对日期序列执行逻辑操作，即CAST( ... AS DATETIME)或<= enddate时，它会将该序列转换为>= startdate。
但是，如果您在SQL Server中的42613上尝试过datetime或DATEADD，您会发现它返回02/09/2016（US：09/02/2016），这就是您返回的原因数据超出了结束日期。此外，如果您尝试CAST，它将在SQL Server上返回42611;与Excel对2016年8月31日日期序列的解释相差2天。
为什么会这样？
Chip Pearson先生在Dates and Times in Excel中解释了这一点，但我会对此进行总结。请记住，当我说日期序列时，我的意思是自19/01/1900以来天已过去。在Excel和SQL Server中，默认日期值均为01/01/1900。但是：
Excel将日期和时间存储为表示自1900年1月1日以来的天数的数字
00/01/1900（美国：01/00/1900）不是有效日期。所以我们必须将任何Excel日期序列偏移-1。为什么这样？
1号代表1900年1月1日。应该注意的是，数字0并不代表1899年12月31日。实际上，这个数字比实际天数大一个。这是因为Excel的行为就像1900年2月29日的日期一样。它没。 1900年不是闰年（2000年是闰年）。在Excel中，1900年2月28日之后的那一天是1900年2月29日。实际上，1900年至2月28日的那一天是1900年3月1日。这不是一个“错误”。实际上，它是设计的。
因此，在您的特定情况下，由于日期序列1代表Excel中的01/01/1900（因为日期序列0是00/01/1900），这是您额外2天的第一天，而闰年2000则是366天而不是365这是你的第二个额外的一天，这就是为什么它返回到包括02/09/2016的数据。
简而言之，您需要将Excel的日期表示形式视为从00/01/1900而不是从01/01/1900开始的日期，以及在SQL Server语句中使用Excel日期序列时的任何闰年。