2

C# の DateTime 文字列が不思議なことに英国の日付 (dd/MM/yyyy) としてフォーマットされているため、SQL DateTime への変換に失敗するという問題があります。一連のイベントは次のとおりです。

  1. 米国のリモート サーバーでオブジェクトが作成され、xml にシリアル化されます。
  2. xml は、CA のローカル コンピューターで逆シリアル化され、オブジェクトに戻されます。シリアル化された日付は次のようになります: 2011-07-13T09:56:57.0542425
  3. アプリケーションは、前述のストアド プロシージャを呼び出して、オブジェクトをデータベースに保存しようとします。Convert.ToString(DateTime) を使用して、日付をパラメーターとして sproc に渡す前に、(不必要に) 日付を文字列に変換します。
  4. sproc は SqlException "Error conversion data type nvarchar to datetime" で失敗します。これは、DateTime 型付きパラメーターに対して受け取った文字列が dd/MM/yyyy 形式であったためです (データベース言語は米国英語です)。

さて、コードは日時を文字列に変換してSQLで日時に戻すだけではいけませんが、1年以上すべてがうまくいった後、この問題が（複数のコンピューターで）発生し始めました。そのため、DB または OS の文化が最近変更され、異なる日付形式が使用されているに違いないと思いました。驚いたことに、OS (Windows 7) を英語 (カナダ) から英語 (米国) に変更して再起動した後も、問題は引き続き発生します。さらに紛らわしいことに、地域設定に関係なく、同じタイプのオブジェクトが逆シリアル化されるのではなくローカルで作成された場合、エラーは発生しません。唯一の違いは、シリアル化バージョンが Windows サービスで発生し、ローカルで作成されたオブジェクト バージョンが Windows アプリで発生することです。どちらも Convert.ToString(DateTime) を呼び出すアセンブリの独自のコピーを使用しますが、そのアセンブリの同じバージョンを使用しています。私は完全に混乱しています。

PS .NET 2.0 & SQL Server 2005

4

3 に答える 3

2

DateTime.ToString()特に必要なカルチャを使用しての形式を強制しないのはなぜですか?または、SQL 関数が期待するものと一致するカスタム形式の規則を指定しないのはなぜですか?

カスタム書式設定については、こちらをご覧ください。文化固有の書式設定については、こちらをご覧ください。

于 2011-08-05T18:50:52.780 に答える
1

DateTime単純な 64 ビット整数を超えるものは何もないと思います。基本的には、日付/時刻のティック数であり、上位 2 ビットでエンコードされた「種類」です。そのため、新しいDateTimeものを作成するとローカルに作成されます。言い換えれば、「同じタイプのオブジェクトがローカルで作成された」場合に何が起こるかについてのあなたの主張を疑うのは残念です。

それが私が調査を開始する場所です-データベース呼び出しを取り除きますが、呼び出しの結果をログに記録するだけですConvert.ToString(serializedDateTime)（Convert.ToString(new DateTime(2011, 7, 25))文字列表現がどちらの方向にあるかを明らかにする日付の例として）。逆シリアル化された値用とローカルに作成された値用の 2 つの異なる日付形式を与えることができれば、本当に驚きます。

デシリアライゼーション (つまり、プロパティDateTimeを取得した結果) の後にどのような「種類」が得られますか? その情報を使用して、正確に等しい値Kindを構築できるはずです。DateTime

于 2011-08-05T18:51:53.817 に答える
1

サービスが間違った地域設定を持つアカウントで実行されている可能性はありますか?

その場合、 Microsoft からのこれらの指示が適用される可能性があります。

于 2011-08-05T19:22:29.650 に答える