4

我喜欢 SQL Server 2008 中的新 DATE 数据类型，但是当我将 DATE 字段与链接服务器（在本例中为 SQL 2005）上的 DATETIME 字段进行比较时，如下所示：

DECLARE @MyDate DATE
SET @MyDate = CONVERT(DATE, GETDATE())

SELECT *
  FROM MySQL2005LinkedServer.SomeDB.dbo.SomeTable
 WHERE SomeDatetimeField < @MyDate

我收到此错误：

OLE DB provider "SQLNCLI10" returned message "Unspecified error".
OLE DB provider "SQLNCLI10" returned message "The scale is invalid.".

“比例无效”显然是因为 Native 客户端正在将 DATE 数据类型传递回链接服务器，并且由于它是 SQL 2005，它不知道如何处理它。对 2008 服务器运行相同的查询就可以正常工作 - SQL Server 能够毫无问题地比较 DATE 和 DATETIME 数据类型。

这是我的问题 - Native Client 是否有原因不会自动将“2009-11-09”的 DATE 值转换为“2009-11-09 00:00:00.000”的 DATETIME，以便之前版本的SQL Server 不会窒息吗？

4

3 回答 3

5

datetime (2005) 和 date / time / datetime2 datetimeoffset (2008) 的内部结构彼此非常不同，并且与其他比较一样，比较时必须将数据放入同一类型。因此，本机客户端将被迫进行这样的转换。

本机客户端可能很慷慨并为您进行隐式转换，但同样，产品倾向于工作的“最不意外的元素”应该建议在 SQL 2005 中抛出它本身不理解的类型应该被拒绝。肯定会出现许多细微的错误。

在 SQL 2005 中抛出 datetime2(7) 也应该如此，我们是否期望它将 100ns 精度四舍五入回到 3.33ms 或抛出和错误 - 我更喜欢错误并进行/接受显式转换。

于 2009-11-09T15:29:10.860 回答
1

我只能猜测这是因为2009-11-09 00:00:00.000不是时区中立的，并且会导致更微妙的错误。如果我错了，请纠正我。

于 2009-11-09T14:41:06.300 回答
0

您可以使用 ALTER SESSION SET NLS_DATE_FORMAT = 'MM/DD/YYYY HH:MI:SS AM'; 这是临时解决方案，如果您在 UNIX 上工作，那么这些设置可以在 .profile 中永久完成。

于 2009-11-09T14:39:50.907 回答