0

そのような質問がすでにSOにたくさんあることは知っていますが、私の質問は既存の質問とは少し異なります。

シナリオ: データベースには、"yyyy-mm-dd hh:mm:ss" 形式の値を持つ DateTime 型の ApptDt 列があります。私はインド出身で、日付はヨーロッパ形式の「dd-mm-yyyy」で渡されます。したがって、このエラーが発生するたびに：

Varchar データ型を datetime に変換すると範囲外の値になる

サンプルクエリ 1: 

  Declare @EffectiveDt as varchar(29)
  Set @EffectiveDt = '27/07/2013'
  print Convert(DateTime,@EffectiveDt,102) // throws above error

サンプルクエリ 2:

Declare @EffectiveDt as varchar(29)
Set @EffectiveDt = '07/27/2013'    
print Convert(DateTime,@EffectiveDt,104) // throws above error too

質問：

  1. 2 つの形式は有効であり、変換は T-Sql で許可されています。なぜそのようなエラーがスローされるのですか?

  2. SQL 内でこのような相互変換を保持する一般的な関数またはシナリオはありますか?

4

3 に答える 3

2

あなたがすべきことは、そもそものような地域形式を使用しないことです。このような明確な文字列形式を使用すると、問題が発生することはなく、あらゆる種類のクレイジーな回避策を見つける必要はありません。そもそも、日付を明確かつ標準的な方法でフォーマットするだけです。d/m/ym/d/yyyyymmdd

インド出身だからといって、地域の文字列を使用して日付を表す必要があるわけではありません。人々に自由なテキストで日付を入力させている場合 (2013 年 7 月 27 日、2013 年 7 月 27 日、2013 年 7 月 27 日になったと説明できる唯一の方法です)、それをやめるか、日付を検証してください。入力。誰かが 2013 年 5 月 6 日と入力した場合、それが 5 月 6 日か 6 月 5 日かをどのように知ることができますか? SQL Server も判断できず、(Access にあるような) 強制的に推測させ、有効でない場合は数値を転置する魔法の方法はありません。それは実際にはかなり恐ろしい行動です。

于 2013-07-30T14:23:29.660 に答える
0

(ドイツ形式)102に変更104

SELECT Convert(DateTime,@EffectiveDt,104)

デモ

于 2013-07-30T14:15:48.223 に答える
0

非常に特定の文化でそれCASTを試みるのではなく、ただそれだけです:CONVERT

SELECT CAST(@EffectiveDt AS DATETIME)
于 2013-07-30T14:15:55.760 に答える