在切换到使用 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 失败了。