2012-01-25 11 views
1

私はプロダクションサーバで青から出てきたエラーに困惑しています。SQL Serverのdatetime変換が動作しなくなった

var mis = from m in dtcx.valori 

        join p in dtcx.TEPARAMs on m.PARAMCD equals p.PARAMCD 
        where 

        blah blah blah 

        select new 
        { 
         dataRilevazione = m.dataRilevazione, 
         id =m.data>=new DateTime(2010,02,26)&&m.X==3&&m.Y==69?100: m.id, 

         blah blha 
        }; 

この条件を持つSQLクエリに変換します:これは魅力のように働いている

@p6='2010-02-26 00:00:00'

N'SELECT [t0].[dataRilevazione], 
    (CASE 
     WHEN ([t0].[data] >= @p6) AND ([t0].[X] = @p7) AND ([t0].[Y] = @p8) THEN @p9 

は私のようなLINQ2SQLクエリをしていますそれは2日前からvarcharからdatetimeへの間違った変換があったと言って動作を停止して以来、年齢のために。

実際問題として、2010-02-26 00:00:00はもはや日付に変換されていません。私は

印刷

convert(datetime,'2010-02-26 00:00:00' ) 

をしようとした場合、私はすべてが働いていたとき、私は、ユーザー、もそのロケール、また私は何も変更していないので、

convert(datetime,'2010-02-26 00:00:00', datetime) 

を使用して消え同じエラーを取得します知っている。

私は何ができるのでしょうか? おかげ

UPDATE:

-- network protocol: TCP/IP 
set quoted_identifier on 
set arithabort off 
set numeric_roundabort off 
set ansi_warnings on 
set ansi_padding on 
set ansi_nulls on 
set concat_null_yields_null on 
set cursor_close_on_commit off 
set implicit_transactions off 
set language us_english 
set dateformat mdy 
set datefirst 7 
set transaction isolation level read committed 

ので、言語がus_englishのために設定されている:SQL Serverのプロファイリング は、LINQ 2 SQLは正しい言語を設定しているようです!変換がまだ失敗するのはなぜですか? すべてのアイデアは高く評価されています...

+1

「SELECT @@ LANGUAGE」は何を返しますか?また、SQL ServerのCONVERT( '2010-02-26 00:00:00'、datetime)の構文解析では不正確なので、常にエラーになります(あなたのためにタイプミスかもしれません)。データ型と値を交換する必要があります(つまり、 'CONVERT(datetime、 '2010-02-26 00:00:00')')。 –

+0

p6パラメータをDECLARE @ p6 datetimeのようなdatetimeに設定しましたか? –

+0

chris、my typo el ninho、linq2sqlによって生成されているため、SQL側で制御できません。 – pomarc

答えて

2

あなたはこのロケールが重要であるとは言いません - あなたはそれが変更されていないと言いますが、私はその前提を慎重に考えます:-)気にするべきことは、米国と英国の日時フォーマットは、フォーマットを「逆転」するときに:

  • 英国のロケールは、日付を見yyyy-dd-mm hh:mm:ss.fff
  • USロケールがyyyy-mm-dd hh:mm:ss.fff

として日付を見ているとあなたは行って、あなたが現在使用している言語/ロケールを確認することができますSELECT @@LANGUAGE

例えば、これはエラーをスロー:あなたはus_englishとするロケールを変更した場合

SET LANGUAGE british 
GO 
SELECT CAST ('1999-01-21 10:11:12.345' AS DATETIME) 
GO 

はしかし、それは正しく解析されます。

保証をしたい場合は、常にyyyy-mm-ddと解釈されますので、厳密にして、日付と時刻の間にTを指定して完全なISO仕様を使用する必要があります。たとえば、1999-01-21T10:11:12.345は同じ方法で解析します両方のロケール。

さらに、日付/時刻データを操作するときに気を付けるもう1つの楽しい話をしました。

Sidenote:いいえ私はマイクロソフトがなぜBlightyの右ポンドでここにyyyy-dd-mmと表示されるのかわからない...私はこのフォーマットに遭遇したことがない。欧州のフォーマットから継承できますか?

+0

おっと!時間と日付の間にZではなく、T、Z - 時間と時間帯の間にある! 8-) –

+1

Doh! Ta :-)固定。メモリを信頼してすぐに回答を打つ... –

+0

今、その+1 +1 –

0

異なる結果を参照してください:

SET LANGUAGE English 
SELECT convert(DATETIME, '2010-02-01 00:00:00') 
SET LANGUAGE French 
SELECT convert(DATETIME, '2010-02-01 00:00:00') 
SET LANGUAGE Italian 
SELECT convert(DATETIME, '2010-02-01 00:00:00') 

結果は以下のとおりです。

2010-02-01 00:00:00.000 
2010-01-02 00:00:00.000 
2010-01-02 00:00:00.000 

そして、あなたの例のように、フランスとnew DateTime(2010,02,26)イタリアまたは同様の言語を使用すると、このエラーに

を引き起こす可能性があります

セッションオプションを確認するにはDBCC USEROPTIONS - 言語オプションは特に

関連する問題