Тег: sql-server

Это определяет версия EF Core у провайдера SQL Server в вашем стартовом проекте: EF Core 7 и более ранние создают для date тип DateTime, EF Core с 8 по 11 создают DateOnly. Здесь показано сопоставление типов, которое принимает решение, измеренный результат для EF Core 7, 8, 10 и 11 RC 2, а также два способа вернуть DateTime, не переключив столбец незаметно на datetime2.

EF.Constant встраивает захваченное значение в SQL как литерал, EF.Parameter превращает литерал в SQL-параметр. Оставляйте поведение EF Core по умолчанию, используйте EF.Parameter, чтобы динамически построенные деревья выражений не перекомпилировались при каждом вызове, а EF.Constant применяйте только для значений с небольшим набором вариантов и настолько перекошенными данными, что каждому нужен свой план.

HasIndex(...).IsUnique() на члене ToJson() не обеспечивает уникальность в EF Core 11 RC 1: SQL Server отбрасывает IsUnique, а SQLite индексирует весь документ. Вынесите значение JSON в вычисляемый столбец и поставьте уникальный индекс на него.

Проверка на существование в обработчике не та защита, за которую вы её принимаете. Поставьте уникальный индекс на таблицу inbox, пишите маркер в том же SaveChanges, что и бизнес-изменение, и пусть победителя выбирает база данных. Плюс ловушка с ExecuteUpdate, которая молча сводит всё это на нет.

Переименуйте все PK_, FK_, AK_ и IX_, которые генерирует EF Core 11, с помощью одного IModelFinalizingConvention, сохраните приоритет явно заданных имён, уложитесь в ограничение длины идентификатора и избегите перестроения кластеризованного индекса, которое следующая миграция сгенерирует для существующей базы данных.

Используйте Microsoft.Data.SqlClient. System.Data.SqlClient объявлен устаревшим, уже выдаёт CS0618 на каждый тип, к которому вы прикасаетесь, и теряет свои .NET-ассеты, когда .NET 8 достигнет конца поддержки 2026-11-10, в тот же день, когда выходит .NET 11. Измеренный разрыв в возможностях, значение Encrypt по умолчанию, ломающее миграцию, и разделение пакета в 7.0.

EF Core 11 теперь по умолчанию задаёт для UseSqlServer уровень совместимости 160, из-за чего в ваш SQL попадают LEAST, GREATEST и двухаргументные LTRIM/RTRIM, в том числе в каждом Take(n).FirstOrDefault(). Оставляйте 160 на SQL Server 2022 и новее; закрепите UseCompatibilityLevel(150), если хоть одно окружение ещё работает на SQL Server 2019.

Проверка существования базы в провайдере SQL Server для EF Core повторяет ошибку 18456 целую минуту, с EnableRetryOnFailure или без него. Падайте сразу, ограничьте RetryTimeout или дождитесь EF Core 12.

EF Core 11 скомпилирован против Microsoft.Data.SqlClient 7.0.0.0, но при восстановлении пакетов или развёртывании победила копия 6.x. Удалите старую фиксацию версии SqlClient и заново разверните весь вывод сборки.

StartsWith, EndsWith и Contains в EF Core 11 уже сами экранируют % и _, а EF.Functions.Like этого не делает. Разбираем SQL, который генерирует EF, переиспользуемый помощник для экранирования и перегрузку с escapeCharacter, благодаря которой всё работает в SQL Server, SQLite и PostgreSQL.