タグ: sql-server

EF.Constant はキャプチャした値を SQL リテラルとして埋め込み、EF.Parameter はリテラルを SQL パラメーターに変換します。基本は EF Core の既定のままにし、動的に組み立てた式ツリーが呼び出しのたびに再コンパイルされるのを防ぐには EF.Parameter を使います。EF.Constant は、値の種類が少なく、データの偏りが大きくて値ごとに別のプランが必要な場合だけに使います。

EF Core 11 RC 1 では、ToJson() メンバーに対する HasIndex(...).IsUnique() は一意性を強制しません。SQL Server は IsUnique を無視し、SQLite はドキュメント全体にインデックスを張ります。JSON の値を計算列として公開し、その列に一意インデックスを設定してください。

ハンドラーの存在チェックは、あなたが思っているようなガードではありません。inbox テーブルに一意インデックスを張り、業務上の変更と同じ SaveChanges でマーカーを書き込み、勝者はデータベースに決めさせます。さらに、それを静かに台無しにする ExecuteUpdate の罠も扱います。

EF Core 11 が生成する PK_、FK_、AK_、IX_ の名前を 1 つの IModelFinalizingConvention ですべて付け替え、明示的に指定した名前を優先させ、識別子の長さ制限に収め、既存データベースで次のマイグレーションが生成するクラスター化インデックスの再構築を回避します。

Microsoft.Data.SqlClient を使ってください。System.Data.SqlClient は非推奨で、触れる型すべてに CS0618 が出ます。さらに .NET 8 が 2026-11-10 にサポート終了を迎えると .NET 向けアセットが削除されます。その日は .NET 11 のリリース日でもあります。実測した機能差、マイグレーションを壊す Encrypt の既定値、そして 7.0 でのパッケージ分割について解説します。

EF Core 11 では UseSqlServer の既定の互換性レベルが 160 になり、LEAST、GREATEST、2 引数の LTRIM/RTRIM が SQL に入るようになりました。すべての Take(n).FirstOrDefault() も対象です。SQL Server 2022 以降なら 160 のままにし、SQL Server 2019 がまだ動いている環境が一つでもあれば UseCompatibilityLevel(150) で固定してください。

EF Core の SQL Server 存在チェックは、EnableRetryOnFailure の有無にかかわらずエラー 18456 を丸 1 分間リトライします。即座に失敗させるか、RetryTimeout を短くするか、EF Core 12 を待ってください。

EF Core 11 は Microsoft.Data.SqlClient 7.0.0.0 に対してコンパイルされていますが、リストアまたはデプロイで 6.x のコピーが採用されてしまっています。古い SqlClient の固定指定を削除し、出力全体を再デプロイしてください。

EF Core 11 では StartsWith、EndsWith、Contains が % と _ を自動でエスケープしますが、EF.Functions.Like はエスケープしません。EF が生成する SQL、再利用できるエスケープヘルパー、そして SQL Server、SQLite、PostgreSQL で正しく動作させるための escapeCharacter オーバーロードを解説します。

SQL Server 2025 と Azure SQL ではネイティブの json 型を使いましょう。EF Core 11 はそこから JSON_CONTAINS、型付きの JSON_VALUE、インプレースの modify()、JSON インデックスを引き出せます。SQL Server 2019/2022、レガシーなツール、あるいはロールバックできる必要があるスキーマの場合は nvarchar(max) のままにしてください。