“<>” по сравнению с “НЕ В”
Я думаю, что вы пропустили вызов AddRoleManager. Вот аналогичная настройка, которую я имел, попробуйте:
services.AddIdentity<IdentityUser, IdentityRole>(o => {
o.Password.RequiredLength = 8;
})
.AddRoles<IdentityRole>()
.AddRoleManager<RoleManager<IdentityRole>>()
.AddDefaultTokenProviders()
.AddEntityFrameworkStores<ApplicationDbContext>();
8 ответов
SELECT something
FROM someTable
WHERE idcode NOT IN (SELECT ids FROM tmpIdTable)
проверяет любое значение в списке.
Однако NOT IN не является нулевым. Если подзапрос вернул набор значений, содержащих NULL, никакие записи не вернулись бы вообще. (Это потому, что внутри NOT IN оптимизирован для idcode <> 'foo' AND idcode <> 'bar' AND idcode <> NULL и т. Д., Что всегда будет терпеть неудачу, потому что любое сравнение с NULL дает UNKNOWN, предотвращение того, чтобы все выражение когда-либо стало ИСТИННЫМ.)
Лучше, Вариант с нулевым допуском будет следующим:
SELECT something
FROM someTable
WHERE NOT EXISTS (SELECT ids FROM tmpIdTable WHERE ids = someTable.idcode)
РЕДАКТИРОВАТЬ: Я изначально предполагал, что это:
SELECT something
FROM someTable
WHERE idcode <> (SELECT ids FROM tmpIdTable)
будет проверять только первое значение. Оказывается, это предположение неверно, по крайней мере для SQL Server, где оно фактически вызывает его ошибку:
Msg 512, Level 16, State 1, Line 1 Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, <, <= , >, >= or when the subquery is used as an expression.
Этот код действителен тогда и только тогда, когда из tmpIdTable не было возвращено ни одной строки:
SELECT something
FROM someTable
WHERE idcode <> (SELECT ids FROM tmpIdTable)
Если возвращено несколько строк, вы получите сообщение об ошибке вида:
Msg 512, уровень 16, состояние 1, строка 1 Подзапрос вернул более одного значения. Это недопустимо, если подзапрос следует за =,! =, <, <=,>,> = Или когда подзапрос используется в качестве выражения.
Это та же ошибка, которую вы получаете с вложенным скаляром, неожиданно создает несколько строк, например :
SELECT *, (SELECT blah FROM t1 WHERE и т. Д.) FROM t2
Ничего не изменилось WRT this в SQL Server за десять лет, поэтому я ожидаю, что предположения о вложенном запросе в исходном коде были нарушены.
Если строки не возвращены, результат будет пустым, поскольку <> NULL никогда не будет истинным (предположим, что ANSI NULL).
Этот код действителен для любого количества строк:
SELECT something
FROM someTable
WHERE idcode NOT IN (SELECT ids FROM tmpIdTable)
Однако, все еще могут быть проблемы с NULL.
попробуйте это, может работать быстрее из-за использования индекса:
SELECT something
FROM someTable
LEFT OUTER JOIN tmpIdTable ON idcode=ids
WHERE ids IS NULL
<> - это «сингулярная» НЕ операция; NOT IN - это операция установки, поэтому логично, что первая не будет работать. Однако я понятия не имею, могло ли это сделать в предыдущей версии SQL Server.
Я понятия не имею, зачем вам писать что-то вроде WHERE idcode < > (ВЫБЕРИТЕ идентификаторы ИЗ tmpIdTable) . Оператор SELECT вернет набор кортежей, и ваш idcode будет или НЕ будет В этом наборе. « WHERE idcode NOT IN (SELECT ids FROM tmpIdTable) » - способ сделать это.
Если подзапрос SELECT возвращает нулевые строки, это NULL. Когда NULL сравнивается с чем-либо, результат всегда UNKNOWN и никогда не TRUE. Как ни странно, NOT UNKNOWN равно UNKNOWN.
Я по возможности избегаю трехзначной логики (ИСТИНА, ЛОЖЬ, НЕИЗВЕСТНО). Этого не так уж и сложно избежать, как только вы освоитесь.
Если подзапрос SELECT возвращает ровно одно значение, сравнение на неравенство должно вернуть ожидаемый результат.
Если подзапрос SELECT возвращает более одного значения, вы должны получить сообщение об ошибке.
Как правило, NOT IN вернет результат, который вы ожидаете при проверке отсутствия членства в наборе.
Этот ответ перекрывает другие ответы, но он сформулирован немного иначе.
Отредактировано, чтобы добавить больше деталей о НЕ В:
Я немного искал НЕ В в Oracle, и я узнал кое-что, чего не знал полчаса назад. NOT IN чувствителен к NULL. В частности,
X NOT IN (SELECT ...)
- это не то же самое, что
NOT (X IN SELECT ...))
Мне, возможно, придется изменить свой предыдущий ответ!
в некоторых версиях SQL ! = следует использовать для логического оператора «не равно». Вы пробовали это?