当通过参数向存储过程提供日期时，我对于日期使用哪种格式有些困惑。我最初的VBA语法使用ADO Connection对象执行存储过程：

Set SentDetailRS = Me.ADOConnectionToIntegrity.Execute("dbo.s_SelectAggregatedSentDetailList '" & fCSQLDate(EffectiveDate) & "'", , adCmdText)

使用日期语法" yyyy-mm-dd"对我来说很好用，但是当另一个用户执行代码时，他们会收到错误：13'Type Mismatch'。

经过一些试验，我发现以" dd / mm / yyyy"格式提供日期可以为用户解决此错误，但现在却给了我错误！

不管日期的格式如何，都可以使用带有参数的命令对象执行存储过程(我假设ADO负责幕后的格式化)。我以为使用yyyy-mm-dd格式可以在SQL Server上普遍使用？

我也困惑为什么这个问题似乎是特定于用户的？我注意到我在SQL Server上的默认语言是"英语"，而另一个用户的默认语言是"英国英语"，这可能会引起问题吗？

我将ADO 2.8与Access 2003和SQL Server 2000一起使用，SQL Server登录是通过Windows集成安全性进行的。

解决方案

回答

我猜想fCSQLDate函数是特定于区域性的，即它将基于用户的语言环境设置来解析日期。这就是为什么我们看到问题。

无论如何，将查询与串联字符串一起使用总是一个坏主意(注入攻击)。如果使用参数，效果会更好。

回答

Access用作日期字段定界符。格式应为＃mm / dd / yyyy，可能＃mm-dd-yyyy也可以正常使用。

回答

请当心，不要相信ADO会解决这个问题。通用SQL日期格式为" YYYYMMDD"，而SQL和ACCESS都受计算机的区域设置影响，它们显示日期并将其转换为字符串的方式。

不要忘记日期分隔符在Access中，而在SQL中则为'

我最好的建议是在将指令发送到服务器之前，将Access＃MM-DD-YYYY(或者类似名称)系统地转换为" YYYYMMDD"。我们可以构建一个小的函数，例如：

Public function SQLdateFormat(x_date) as string

SQLDateFormat = _
   trim(str(datePart("yyyy",x_date))) & _
   right(str(datePart("m",date)),2) & _
   right(str(datePart("d",date)),2)

   ''be carefull, you might get something like '2008 9 3'
SQLDateFormat = replace(functionSQLDateFormat," ","0")
   '' you will have the expected '20080903'

End function

如果我们没有在将其发送到服务器之前未通过编程方式构建INSERT / UPDATE字符串，则建议我们将所有计算机的区域设置转换为承载SQL的计算机的区域设置。我们可能还需要检查SQL服务器上是否有特定的日期格式(我不确定)。我个人解决了这种本地化问题(当逗号用作法语的十进制分隔符时也发生了这种情况)或者SQL特定字符的问题(当字符串中包含引号或者双引号时)，方法是在将它们发送到服务器。

回答

抱歉，我不了解mysql，但是对于oracle，我总是会明确声明我期望的格式，例如：" DD-MM-YYYY"，以避免(区域)日期格式问题

回答

为什么不使用格式

dd mmm yyyy

只有一种方法可以解释它。

回答

我们可以使用Date()函数根据机器日期和时间设置返回通用日期。机器上的区域设置将决定其在客户端上格式化的方式。如果我们将该字段保留为DateTime字段，则区分区域设置可以格式化日期。

使用Date()函数进入服务器应该也可以正常工作(返回通用日期值)。

另外，在传递查询时，请在查询中使用命令对象和参数，以避免对字符串字段进行SQL注入攻击。