Разница в работе 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 **[ТС]**

Так и сделал

Новые блоги и статьи Все статьи Все блоги /
Запрет удаления строк ТЧ документа при определенном условии Maks 19.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "Аккумуляторы", разработанного в конфигурации КА2. У данного документа есть ТЧ, в которой в зависимости от прав доступа. . .	Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .
Знаешь почему 90% людей редко бывают счастливыми? kumehtar 14.04.2026 Потому что они ждут. Ждут выходных, ждут отпуска, ждут удачного момента. . . а удачный момент так и не приходит.	Фиксация колонок в отчете СКД Maks 14.04.2026 Фиксация колонок в СКД отчета типа Таблица. Задача: зафиксировать три левых колонки в отчете. Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) / / . . .	Настройки VS Code Loafer 13.04.2026 { "cmake. configureOnOpen": false, "diffEditor. ignoreTrimWhitespace": true, "editor. guides. bracketPairs": "active", "extensions. ignoreRecommendations": true, . . .	Оптимизация кода на разграничение прав доступа к элементам формы Maks 13.04.2026 Алгоритм из решения ниже реализован на нетиповом документе, разработанного в конфигурации КА2. Задачи, как таковой, поставлено не было, проделанное ниже исключительно моя инициатива. Было так:. . .

@Usaga 14319 / 9404 / 1356 Регистрация: 21.01.2016 Сообщений: 35,468
	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 14319 / 9404 / 1356 Регистрация: 21.01.2016 Сообщений: 35,468
	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 14319 / 9404 / 1356 Регистрация: 21.01.2016 Сообщений: 35,468
	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 14319 / 9404 / 1356 Регистрация: 21.01.2016 Сообщений: 35,468
	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 14319 / 9404 / 1356 Регистрация: 21.01.2016 Сообщений: 35,468
	19.03.2020, 14:08
	galeks1, я бы поставил уровень совместимости пониже и не парился бы. 0

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