SQL Server データベースに接続された Linq DataContext を使用して INSERT を実行すると、SqlDateTime オーバーフロー エラー (1753 年 1 月 1 日 12:00:00 AM から 9999 年 12 月 31 日 11:59:59 PM の間にある必要があります) が発生します。 SubmitChanges() を実行します。
デバッガーを使用すると、日付の値は正しいです。コードを一時的に更新して日付値を DateTime.Now に設定しても、挿入は行われません。
この動作の回避策を見つけた人はいますか? データコンテキストがデータベースに送信する SQL を確認する方法があるかもしれません。
正しい日付列を見ていますか? 一度私に起こりましたが、エラーは、送信前に設定されていなかった別のnull不可の日付列が原因であることが判明しました。
デザイナーでフィールドを自動生成として設定していますか? それが問題でない場合は、コンソールへのデータ コンテキスト アクションのログ記録を設定し、生成された実際の SQL をチェックして、その列が挿入されていることを確認してから、逆方向にトレースして問題を見つけることをお勧めします。
context.Log = Console.Out;
FWIW、デザイナーで「CreatedTime」列と「LastUpdatedTime」列を自動生成（および読み取り専用）として設定し、適切なデフォルトを設定するか、DB トリガーを使用して挿入または更新時に値を設定することがよくあります。自動生成として設定すると、変更されても挿入/更新に含まれません。列で null が許可されていない場合は、値を設定する別の手段、つまりデフォルトの制約やトリガーを指定する必要があります。
最近これに出会いました。エラーは、「何かが保存を妨げています!」と言うかもしれません。私の場合、問題は DateTime 値ではなかったからです。
主キーに値を渡していると思ったのですが、届いたのは「null」でした。キーであるため、null にすることはできません。したがって、私の問題は完全に別の場所にありました。ヌルを解決することで、問題はなくなりました。
私たちは皆、誤解を招くエラーを嫌います。これもその 1 つです。
最後に、提案として...日付の変換に問題がある場合は、日付をまったく使用しないでください。.NET の DateTime クラスは、"Ticks" 値をサポートしています。また、新しい DateTime(ticks) をインスタンス化することもできます。それも。その唯一の落とし穴は、Javascript での目盛りの実装が歴史の中で異なる出発点を持っていることです。そのため、C# から Javascript に DateTimes を取得しようとしたことがある場合は、ティック間の変換が必要になる場合があります。
プロジェクトのターゲット フレームワークを変更することをお勧めします。おそらく、SQL Server は .Net Framework よりも新しいものです。あなたの問題も同じです。
私のプロジェクトのターゲット フレームワークは 3.5 です。
SQL Server は 2012 年です
そして、4.0 に変更します。問題は解決しました。