Разница в работе LINQ EF6.2 в зависимости от режима совместимости базы данных

@galeks1 · Регистрация: 06.03.2018

Студворк — интернет-сервис помощи студентам

есть linq запрос к базе данных:

C#
1
2
3
4
                    var q = (from cr in dBContext.CheckRecords
                            from u in dBContext.Users
                            where cr.MesId == _selRec.Rec.Id && cr.NumJ == (int)JournalType.teh && ((cr.Ch ?? 0) == 1) && _selRec.Rec.DateLastEd == cr.DateChange && u.id == cr.UserId
                            select new NamedCheckRecord { Crec = cr, F = u.f, I = u.i, O = u.o });

При повышении уровня совместимости базы данных до SQL Server 2017 (140) запрос перестает корректно отрабатываться при тех же входных данных которые были при режиме совместимости SQL Server 2014 (120) и ниже.

Опытным путем пришел, к тому, что перестает работать сравнение двух дат :

C#
1
_selRec.Rec.DateLastEd == cr.DateChange

где _selRec.Rec.DateLastEd имеет тип DateTime?, а cr.DateChange имеет тип DateTime.

как добиться того, чтобы независимо от уровня совместимости базы данных сравнение дат работало корректно?

@Usaga · 18.03.2020, 12:57

galeks1, вопрос стоит неправильно. Смотреть надо на сгенерированный SQL, на место, где идёт сравнение дат. Сравнить текст запроса для разных уровней совместимости, чтобы понять EF это разные запросы формирует или поведение СУБД меняется. И от этого уже плясать.

@galeks1 · 18.03.2020, 13:24 **[ТС]**

смотрел, ничего внятного...
При попытке запустить полученный запрос EF в SSMS все отрабатывает хорошо.

Скорей всего это связано с тем, что начиная с MS SQL 2016 EF6 переводит DateTime в datetime2 по разному
т.е. в базе одно и тоже значение при MS SQL 2014 приходит как :
2019-11-13 15:00:29.5870000
при MS SQL 2017 :
2019-11-13 15:00:29.5866667
но в обоих случаях сравнивается с значением 2019-11-13 15:00:29.587

Поэтому в первом случае запрос работает, а во втором нет.

Добавлено через 6 минут
вот этот запрос проверен на разных уровнях совместимости.
запрос реальный из EF6.2
Вначале только подставлены данные из переменных.

T-SQL
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
declare @p__linq__0 as bigint, @p__linq__1 as DATETIME2;
 
set @p__linq__0 = 2473;
 
select  @p__linq__1= m.DateLastEd  from JTMessage m where m.Id = @p__linq__0;
 
select @p__linq__1;
 
 
SELECT 
    [Extent1].[NumJ] AS [NumJ], 
    [Extent1].[Id] AS [Id], 
    [Extent1].[MesId] AS [MesId], 
    [Extent1].[UserId] AS [UserId], 
    [Extent1].[DateChange] AS [DateChange], 
    [Extent1].[Ch] AS [Ch], 
    [Extent1].[DateCheck] AS [DateCheck], 
    [Extent2].[f] AS [f], 
    [Extent2].[i] AS [i], 
    [Extent2].[o] AS [o]
    FROM  [dbo].[CheckRecord] AS [Extent1]
    INNER JOIN [dbo].[Users] AS [Extent2] ON [Extent2].[id] = [Extent1].[UserId]
    WHERE ([Extent1].[MesId] = @p__linq__0) AND (0 = [Extent1].[NumJ]) AND (1 = (CASE WHEN ([Extent1].[Ch] IS NULL) THEN 0 ELSE [Extent1].[Ch] END)) AND (@p__linq__1 = [Extent1].[DateChange])

Как раз получается тот результат с датами который описан выше

@Usaga · 18.03.2020, 13:27

Сообщение от galeks1

При попытке запустить полученный запрос EF в SSMS все отрабатывает хорошо.

Значит EF всё сделал правильно.

Добавлено через 1 минуту

Сообщение от galeks1

@p__linq__1

А что сюда подставляется в случае, когда запрос работает и в случае, когда нет?

@galeks1 · 18.03.2020, 13:34 **[ТС]**

Туда подставляется в случае когда работает :

Сообщение от galeks1

2019-11-13 15:00:29.5870000

В случае когда не работает

Сообщение от galeks1

2019-11-13 15:00:29.5866667

Добавлено через 1 минуту
Может глюки из за того, что сама база изначально была создана в MS SQL 2005?

@Usaga · 18.03.2020, 13:47

Сообщение от galeks1

Может глюки из за того, что сама база изначально была создана в MS SQL 2005?

Не, вряд ли.

Похоже это поведение EF'а не только вас расстроило.

@galeks1 · 18.03.2020, 13:50 **[ТС]**

Да, видел эту статью уже после опубликования поста.
Была надежда может в EF6.4 что то поменялось.

Буду ограничивать совместимость до MS SQL 2014

@Usaga · 18.03.2020, 13:57

galeks1, не обязательно ограничивать совместимость. Просто нужно изменить логику сравнения дат в запросе откинув миллисекунды до нужной точности.

Добавлено через 1 минуту
В общем, или округлять миллисекунды в DateTime до сотых, или сравнивать даты по компонентам (годы, месяцы, дни...).

Добавлено через 1 минуту
Вообще, это очень полезная для меня информация. Я не знал о таком дебильном поведении EF'а на свежих версиях SQL Server'а.

@carrotik · 18.03.2020, 15:54

Эта цитата из переписки радует ..

We have developers at our company actively working on converting our code from EF to EF Core since it does not have this problem.

@Usaga · 18.03.2020, 17:03

carrotik, на самом деле меня это немного удивило. По своему опыту я знаю (может ошибаюсь?), что прямое сравнение дат не такое частое явление при работе с СУБД. Чаще промежутки ищут. Да и то не каждый запрос дату включает.

Мне кажется, что было бы проще и дешевле прошерстить все места, где есть прямое сравнение дат и там вкорячить округление или сравнение по компонентам даты или ещё какое местечковое решение применить, чем ВЕСЬ проект переводить на другую ORM.

@carrotik · 18.03.2020, 17:18

Usaga, я вообще, там где можно, т.е. нет часово-минутно-секундной точности, использую сравнение "больше вчерашней, меньше завтрашней", хотя это и добавляет кода ...

@Usaga · 18.03.2020, 17:23

carrotik, кстати, чем вызвана необходимость поднятия версии совместимости до 140? Мы только в том месяце подняли до 110 чисто из-за одной аггрегатной функции и потому, что SQL Server 2008 R2 официально всё (что оправдывает попытку использовать какие-то полезняшки из более новой версии сервера).

@carrotik · 18.03.2020, 17:32

Usaga, .это вопрос скорее к ТС ..

... но судя по параллельной его теме, у него не работала функция SqlFunctions.DateDiff ...

@galeks1 · 19.03.2020, 12:57 **[ТС]**

Совсем недавно у нас стоял только MS SQL 2005. И все прекрасно работало.
Но сторонние разработчики ПО которое у нас используется не дремлют и в новых версиях стало не возможно использовать 2005. Пришлось покупать то, что было поновее. Это и оказался 2017.

Добавляя новые возможности в свое по столкнулся с тем, что MS 2005 не поддерживает некоторые возможности EF6.2 (Например SqlFunctions.DateDiff из за того что нет типа данных time). Ну и перенес базу на 2017 и поставил максимальную совместимость (

, а чего мелочиться то

). Сотлкнулся с частичной потерей функциональности ПО описанной выше.

все просто...

@Usaga · 19.03.2020, 14:08

galeks1, я бы поставил уровень совместимости пониже и не парился бы.

@galeks1 · 19.03.2020, 16:46 **[ТС]**

Так и сделал

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .

@Usaga 14292 / 9377 / 1352 Регистрация: 21.01.2016 Сообщений: 35,338
	18.03.2020, 12:57
	galeks1, вопрос стоит неправильно. Смотреть надо на сгенерированный SQL, на место, где идёт сравнение дат. Сравнить текст запроса для разных уровней совместимости, чтобы понять EF это разные запросы формирует или поведение СУБД меняется. И от этого уже плясать. 0

@galeks1 60 / 45 / 15 Регистрация: 06.03.2018 Сообщений: 202
	18.03.2020, 13:50 [ТС]
	Да, видел эту статью уже после опубликования поста. Была надежда может в EF6.4 что то поменялось. Буду ограничивать совместимость до MS SQL 2014 0

@Usaga 14292 / 9377 / 1352 Регистрация: 21.01.2016 Сообщений: 35,338
	18.03.2020, 13:57
	galeks1, не обязательно ограничивать совместимость. Просто нужно изменить логику сравнения дат в запросе откинув миллисекунды до нужной точности. Добавлено через 1 минуту В общем, или округлять миллисекунды в DateTime до сотых, или сравнивать даты по компонентам (годы, месяцы, дни...). Добавлено через 1 минуту Вообще, это очень полезная для меня информация. Я не знал о таком дебильном поведении EF'а на свежих версиях SQL Server'а. 0

@carrotik 800 / 583 / 207 Регистрация: 21.02.2019 Сообщений: 2,095
	18.03.2020, 15:54
	Эта цитата из переписки радует .. We have developers at our company actively working on converting our code from EF to EF Core since it does not have this problem. 0

@Usaga 14292 / 9377 / 1352 Регистрация: 21.01.2016 Сообщений: 35,338
	18.03.2020, 17:03
	carrotik, на самом деле меня это немного удивило. По своему опыту я знаю (может ошибаюсь?), что прямое сравнение дат не такое частое явление при работе с СУБД. Чаще промежутки ищут. Да и то не каждый запрос дату включает. Мне кажется, что было бы проще и дешевле прошерстить все места, где есть прямое сравнение дат и там вкорячить округление или сравнение по компонентам даты или ещё какое местечковое решение применить, чем ВЕСЬ проект переводить на другую ORM. 1

@carrotik 800 / 583 / 207 Регистрация: 21.02.2019 Сообщений: 2,095
	18.03.2020, 17:18
	Usaga, я вообще, там где можно, т.е. нет часово-минутно-секундной точности, использую сравнение "больше вчерашней, меньше завтрашней", хотя это и добавляет кода ... 0

@Usaga 14292 / 9377 / 1352 Регистрация: 21.01.2016 Сообщений: 35,338
	18.03.2020, 17:23
	carrotik, кстати, чем вызвана необходимость поднятия версии совместимости до 140? Мы только в том месяце подняли до 110 чисто из-за одной аггрегатной функции и потому, что SQL Server 2008 R2 официально всё (что оправдывает попытку использовать какие-то полезняшки из более новой версии сервера). 0

@carrotik 800 / 583 / 207 Регистрация: 21.02.2019 Сообщений: 2,095
	18.03.2020, 17:32
	Usaga, .это вопрос скорее к ТС .. ... но судя по параллельной его теме, у него не работала функция SqlFunctions.DateDiff ... 0

@galeks1 60 / 45 / 15 Регистрация: 06.03.2018 Сообщений: 202
	19.03.2020, 12:57 [ТС]
	Совсем недавно у нас стоял только MS SQL 2005. И все прекрасно работало. Но сторонние разработчики ПО которое у нас используется не дремлют и в новых версиях стало не возможно использовать 2005. Пришлось покупать то, что было поновее. Это и оказался 2017. Добавляя новые возможности в свое по столкнулся с тем, что MS 2005 не поддерживает некоторые возможности EF6.2 (Например SqlFunctions.DateDiff из за того что нет типа данных time). Ну и перенес базу на 2017 и поставил максимальную совместимость ( , а чего мелочиться то ). Сотлкнулся с частичной потерей функциональности ПО описанной выше. все просто... 0

@Usaga 14292 / 9377 / 1352 Регистрация: 21.01.2016 Сообщений: 35,338
	19.03.2020, 14:08
	galeks1, я бы поставил уровень совместимости пониже и не парился бы. 0

@galeks1 60 / 45 / 15 Регистрация: 06.03.2018 Сообщений: 202
	19.03.2020, 16:46 [ТС]
	Так и сделал 0