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.".

「スケールが無効です」というのは、明らかに、ネイティブ クライアントが 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 に答える