Question

通过参数向存储过程提供日期时，我对使用哪种格式的日期感到困惑。我原来的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集成安全性。

Answer 1

小心，不要相信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服务器上是否存在特定的日期格式（我不确定）。 Personnaly，我解决了这种本地化问题（它也发生在昏迷用作法语中的小数分隔符时）或SQL特定字符问题（当引号或双引号都在字符串中时）通过撤回SQL指令然后将它们发送到服务器。

Answer 2

我猜测fCSQLDate函数是特定于文化的 - 即它将根据用户的语言环境设置解析日期。这就是你看到问题的原因。

无论如何，使用带有连接字符串的查询总是一个坏主意（注入攻击）。如果你使用参数，你会更好。

Answer 3

Access使用＃作为日期字段分隔符。格式应该是#mm / dd / yyyy＃可能＃mm-dd-yyyy＃也可以正常工作。

Answer 4

抱歉，我不知道mysql，但是对于oracle，我总是会明确说明我期望格式的格式，例如：'DD-MM-YYYY'，以避免（区域）日期格式问题< / p>

Answer 5

为什么不使用格式

dd mmm yyyy

只有一种方法可以解释。

Answer 6

您可以使用日期（）功能根据机器日期和时间设置返回通用日期。机器上的区域设置将决定它在客户端的格式。如果您将该字段保留为严格的DateTime字段，则cleint区域设置可以格式化日期。

使用Date（）函数进入服务器应该aslo工作（返回通用日期值）。

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

使用日期参数执行存储过程：命令对象与连接对象

6 个答案: