新しいサーバーにアプリケーションをインストールした後、エラーがスローされます。
The conversion of a varchar data type to a datetime data type resulted in an
out-of-range value.
アプリケーションは他のサーバーで適切に動作するため、この問題に戸惑っています。保存される値は
25/4/2012 1:18:01 PM
これは、すでに datetime 列に保存されている DateTime 型であるため、データベースとコード自体に問題はないと確信しています。サーバーの設定が原因で問題が発生した可能性はありますか? 具体的な理由と解決策/回避策はありますか?
次のように、接続ごとに日時形式を設定できます
SET DATEFORMAT dmy
この方法では、SQL Server に送信される日付に d/m/y の日付形式を使用できますが、これは接続に依存します。SQL Server への新しい接続が確立された場合、またはサーバーが停止して再起動された場合、日付形式は m/d/y に戻ります。
フォーマットを永続的に設定する
サーバーで言語を設定するには、sp_addlanguage を使用して言語を追加する必要があります。次の例では、英国英語の言語を設定し、日付を DD/MM/YY 形式で指定します。この例は他の国にも適用できますが、sp_addlanguage のパラメーターを変更する必要がある場合があります。
exec sp_addlanguage 'British', 'English', 'January,February,March,April,May,June,July,August,September,October, November,December', 'Jan,Feb,Mar,Apr,May,Jun,Jul ,Aug,Sep,Oct,Nov,Dec', 'Monday,Tuesday,Wednesday,Thursday,Friday,Saturday,Sunday', dmy,1 sp_configure 'default language', 1 オーバーライドで再構成
詳細については
問題を防ぐ方法。
日付を含むフィードのコンテンツに影響を与える場合は、'Day# MonthName 4digityear' が望ましい形式です。地域設定に関係なく、SQL Server のヒューリスティックは「2012 年 4 月 25 日」について混乱することはありません。これはより堅牢な形式です。それは問題なく海を渡ります。
それ以外の場合は、convert(datetime, TheDateString, CorrectFormatNumber) を使用する必要があります。
131でいいと思います。
ああ、いくつかのコメントをエコーするために、このデータが文字列の形式になるのを防ぐことができるなら、そうするべきです.
良い提案ですが、私の場合、何千行ものコードをわざわざ調べることはできません。SQLの再インストールとインストール中の地域設定の設定は、最も迅速で時間のかからない方法です。
データベースに保存する前にアプリで日時文字列を解析するのは当然のことです。
言語と日付形式の設定は、現在のクエリに対してのみ機能し、行われたすべてのクエリに対しては機能しません。確かに、コードのSQLクエリを更新することは、時間の無駄です。私の場合は、imoです。