0

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

4

6 回答 6

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 服务器上是否有特定的日期格式（我不确定）。个人而言，我通过在将 SQL 指令发送到服务器。

于 2008-09-17T13:56:58.113 回答
0

我猜 fCSQLDate 函数是特定于文化的——即它将根据用户的区域设置解析日期。这就是你看到问题的原因。

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

于 2008-09-17T13:27:24.033 回答
0

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

于 2008-09-17T13:28:19.210 回答
0

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

于 2008-09-17T14:02:58.677 回答
0

为什么不使用格式

dd mmm yyyy

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

于 2008-09-17T23:13:40.240 回答
0

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

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

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

于 2009-06-12T16:57:59.180 回答