1

2つの質問とそれに続く詳細:

  1. ProviderManifestTokenを「2005」に変更すると、他にどのような副作用が発生しますか?
  2. datetimeデータベースのスキーマをからに変更するのは賢明ではありませんdatetime2か?たとえば、ProviderManifestTokenを「2008」のままにして、後で誰かがEDMXモデルからデータベーススキーマを生成しようとしたdatetime2場合、列を作成するときにこれらの列にデータ型を使用しますか?

詳細:

VS2010 SP1
.NET 4
EF 4
SQL Server 2008

私はEntityFrameworkの実践的な経験がなく、それを使用するコードベースを突然維持しています。コードベースは脆弱で、スケジュールが厳しく、残っている人にはまだよく理解されていません。

ソリューションエクスプローラーには、DEVデータベース内の既存のスキーマにマップするEDMXファイルが表示されます。どちら(モデルまたはデータベース)が最初に来たのかわかりません。

コミット操作は次のエラーで失敗します:

datetime2データ型をdatetimeデータ型に変換すると、値が範囲外になりました。

SQL Server 2008インスタンスの日付/時刻列のデータ型を見ると、それらはすべてdatetimeであり、ではありませんdatetime2

EDMXファイルのXMLを見ると、次のスキーマ要素属性が表示されます。

ProviderManifestToken = "2008"

どこかで、SQLServer2008のdatetimeデータ型の範囲外の値を持つDateTime値が.NETコードにあると思います。私は、EDMXのProviderManifestTokenを「2005」に変更すると、EFがdatetime2これらのコミット中にタイプを使用しようとするのを防ぐことができることを読んで収集しました。

私の問題は次のとおりです。2008年から2005年に変更すると、このコードベースまたはEFの位置が他に何が変わるかわかりません。また、絶対に必要でない場合は、テクノロジーを後戻りすることに偏見があります。

4

1 に答える 1

1

ProviderManifestTokenを2005に変更すると、実際には機能しなくなることがいくつかあります。具体的には、SQL2008の時間タイプに関連する関数を使用するLINQクエリです。個人的には、トークンを2005に変更しても問題はありませんでした(複数の環境にまたがる環境ごとでも)...しかし、それは軽視されるべきものではありません。アプリケーション内のすべてのクエリを徹底的にテストする必要があります。

edmxによって逆方向に生成されるスキーマについては、ProviderManifestToken自体ではなく、edmxに関連付けられたSQL生成テンプレートによって決定されます。

于 2011-10-04T15:07:49.400 に答える