文字日期时间及其定界符（＃）。

SQL的ANSI标准指定应立即以m / d / y格式输入文字日期。 在这种情况下，（y）可以指（yy）或（yyyy）。 这完全独立于区域设置。

定界符

日期，时间或日期时间组合的定界符是井号（＃）。 见（

引号（'）和双引号（“）-何时何地使用它们。 ）有关字面定界符格式的更多信息

的

VBA中的Format（）函数可以与这些设置一起使用，以提供所需的字面日期时间（注意，我不知道时间格式方面是否缺乏灵活性，因此我仅将其包括在内以提供可用的示例）：

 Data Type (Example)             Format String     (Required Result) 
Date      (1 February 2003)     '\#m\/d\/yyyy\#'  (#2/1/2003#)
Time      (6:15:42 PM)          '\#hh:n:s\#'      (#18:15:42#)
Date + Time                     '\#m\/d\/yyyy hh:n:s\#'
          (1 February 2003 6:15:42 PM)            (#2/1/2003 18:15:42#)

常见问题

像大多数各种形式的代码解释器（VBA; SQL;等）一样，MS Access Jet SQL解释器可能很聪明（众所周知，MS Access可以宽容），因此即使在日期传递时，也可以在许多情况下正确解释日期文字。格式错误。 例如，以我见过的任何格式都可以正确计算出2005年1月24日的数据。

但是，请考虑上述日期，即2003年2月1日。如果以英国（d / m / yyyy）格式传递，则可以解释为2003年1月2日；如果以yy / m / d格式传递，则可以解释为2001年2月3日。 yyyy / m / d即使不是很标准也应该总是安全的。

如果您要求代码可以（更多）可移植，则坚持使用标准（m / d / y）。

Gotcha

与上一段有关。

要理解的一件事很重要，那就是使用SQL标准以外的格式指定的日期（例如，EG。2015年2月13日的日期指定为＃13/2/2015＃。）仍将被解释为有效日期。如果仍然可以识别它们。 在测试和调试代码时可能很难发现这种情况，因此请务必小心。 通常，这表示所使用的格式不正确，但由于它在本月的13号至月底之间，因此您没有足够的幸运在测试过程中发现它。

注意

除了在SQL格式与本地格式匹配的国家/地区之外，这意味着在VBA中使用字符串时，将以一种方式解释字符串，而在通过SQL解释时，将以另一种方式解释字符串。

区域设置

在处理时，另一个相当讨厌的问题引起了人们的注意

使用其他任何字符替换标准日期格式字符（许多国家（包括美国和英国以及欧洲其他国家）的斜杠（/））的区域设置 。 例如，丹麦等国家/地区的日期格式为（dmy）。 这个问题实际上是VBA和Format（）命令的一个问题。 当标准格式字符串“ m / d / yyyy”由Format（）使用时，将根据“ 区域设置”进行解析和解释，以便将其视为“ md-yyyy”。 当试图为SQL命令字符串生成一致的字符串时，这显然不是一个好消息。 要解决此问题并使其在国际上具有完整的移植性，方法是在格式字符串中的每个斜杠（/）之前使用反斜杠（\），如上面的“ 格式”部分所示。 这确保了反斜杠不会被识别为格式字符，但仍以返回的字符串值结尾在同一位置。 日期变量

将日期变量传递给SQL作为参考时，不需要格式化日期变量（与SQL中的文字字符串相反）。

SQL引擎将正确解释记录中的DateTime字段，在参数查询中输入参数的日期或任何返回DateTime结果的函数

如果它由SQL解释并且没有由Access预处理为日期文字。 在后一种情况下，格式应以标准方式完成。 调试

很容易出错，所以我总是建议在开发代码时，甚至在您知道某个地方存在问题的地方，在将字符串传递给SQL引擎之前，先执行“ Debug.Print strSQL”。 在VBA窗口中使用Ctrl-G来显示并转到显示字符串的立即窗格。

Debug.Print strSQL
DoCmd.RunSQL strSQL

更多

艾伦·布朗（Allen Browne）在此主题上有更多帮助（

访问的国际日期 ）。

From: https://bytes.com/topic/access/insights/575420-literal-datetimes-their-delimiters