6

在切换到使用 SQL Native Client (SQLNCLI) 作为 ADO 的提供程序时，我们的旧应用程序遇到了问题。

我们原来的连接字符串是：

Provider=SQLOLEDB; Server=host; Database=bob; Integrated Security=SSPI;

我们将其更改为：

Provider=SQLNCLI11; Server=host; Database=bob; Integrated Security=SSPI; DataTypeCompatibility=80;

我们发现，在调用存储过程时，使用 adDBTimeStamp 的参数，Native Client 似乎将时间戳视为 smalldatetime，而不是 datetime。这给我们带来了问题，因为我们在某些比较中使用 9999 年 12 月 31 日作为“顶端”日期，而 Native Client 失败并出现“日期格式无效”错误，而 SQLOLEDB 没有问题。

现在看起来我们可以在创建参数时将数据类型从 adDBTimeStamp 更改为 adDate，但是我想知道在我们继续进行代码更改之前连接字符串中是否缺少某些内容。

VBScript 代码重现如下。为免生疑问，在有人建议我们应该使用 12/31/9999 之前，日期格式是英国 (dd/mm/yyyy) :-) 但还要确认，CDate 不会失败。

Set db = CreateObject("ADODB.Command")

' If Provider=SQLOLEDB then there is no error.
db.ActiveConnection = "Provider=SQLNCLI11; Server=host; Database=bob; Integrated Security=SSPI; DataTypeCompatibility=80;"
db.CommandText = "usp_FetchData"
db.CommandType = &H0004

' 135 is adDBTimeStamp
db.Parameters.Append db.CreateParameter("@screenDate", 135, 1, 20, CDate("31/12/9999"))

Set rs = CreateOBject("ADODB.RecordSet")
' Then this line fails with "Invalid date format" from SQLNCLI
rs.Open db

WScript.Echo rs.RecordCount

将日期时间倒回 2078（在 smalldatetime 的日期范围内）会使错误消失。

如前所述，如果可以找到非代码更改修复程序，那就是我们更喜欢的，在我们必须将 adDBTimeStamp 更改为 adDate 之前。我希望 DataTypeCompatiblity=80 表现得像 SQLOLEDB; 不幸的是，在找出 SQLNCLI 使用的映射类型时，我的 Google-fu 失败了。

4

1 回答 1

1

最终可能找到了一个解决方案：通过 MSDN 页面Data Type Support for OLE DB Date and Time Improvements，最后有这个片段：

ITableDefinition::CreateTable 中的数据类型映射

以下类型映射与 ITableDefinition::CreateTable 使用的 DBCOLUMNDESC 结构一起使用：

[...转换表...]

当应用程序在 wType 中指定 DBTYPE_DBTIMESTAMP 时，它可以通过在 pwszTypeName 中提供类型名称来覆盖到 datetime2 的映射。如果指定了datetime，bScale 必须为3。如果指定smalldatetime，bScale 必须为0。如果bScale 与wType 和pwszTypeName 不一致，则返回DB_E_BADSCALE。

在测试中，似乎需要设置适用于 SELECT 和命令以及 CreateTable 的参数的比例。因此，如果我们将上面的脚本更改为：

Set param = db.CreateParameter("@screenDate", 135, 1, 20, CDate("31/12/9999"))
param.NumericScale = 3
db.Parameters.Append param

...然后错误消失并执行存储过程。我们处于测试的早期阶段，但是如果这引起了问题，欢迎其他人提供反馈。

于 2017-02-27T12:10:04.610 回答