Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
не обрабатывается NULL в SELECT...WHERE pole<>1
|
|||
|---|---|---|---|
|
#18+
select * from Table1 where Pole1<>1 не возвращает записи Pole1=NULL Причина? Лекарство? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2001, 12:47 |
|
||
|
не обрабатывается NULL в SELECT...WHERE pole<>1
|
|||
|---|---|---|---|
|
#18+
Лекарство: как всегда - RTFM (т.е. BOL) Причина: Любая операция сравнения с NULL всегда возвращает FALSE. Но имеется такой замечательный оператор, как IS [NOT] NULL. В Вашем случае необходимо переписать условие как: where (IsNull(Pole1,0)<>1) Информацию о функции IsNull можете найти (для тренировки) в BOL (т.е. в Books-On-Line). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2001, 13:04 |
|
||
|
не обрабатывается NULL в SELECT...WHERE pole<>1
|
|||
|---|---|---|---|
|
#18+
SET ANSI_NULLS тады накой? или для выборок он - пустое место? типа диалект ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2001, 13:30 |
|
||
|
не обрабатывается NULL в SELECT...WHERE pole<>1
|
|||
|---|---|---|---|
|
#18+
Дык я ж не зря BOL почитать советую: When SET ANSI_NULLS is OFF, the Equals (=) and Not Equal To (<> comparison operators do not follow the SQL-92 standard. A SELECT statement using WHERE column_name = NULL returns the rows with null values in column_name. A SELECT statement using WHERE column_name <> NULL returns the rows with nonnull values in the column. In addition, a SELECT statement using WHERE column_name <> XYZ_value returns all rows that are not XYZ value and that are not NULL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2001, 14:08 |
|
||
|
не обрабатывается NULL в SELECT...WHERE pole<>1
|
|||
|---|---|---|---|
|
#18+
Небольшое дополнение. Никогда не советую использовать функции в WHERE clause. Это скорее всего приведет к неиспользованию индекса, если таковой был на столбцах, указанных в WHERE clause. Вместо этого лучше сказать WHERE (Pole1 IS NULL OR Pole1 <> 1) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2001, 05:03 |
|
||
|
не обрабатывается NULL в SELECT...WHERE pole<>1
|
|||
|---|---|---|---|
|
#18+
Слон, ты - супер! Напомню, что секция типа WHERE PurchDate > GETDATE() с функцией приведет к использованию индекса, если он есть. Почему? Потому что PurchDate > GETDATE() является 'аргументом поиска' (search argument, SARG). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2001, 08:11 |
|
||
|
не обрабатывается NULL в SELECT...WHERE pole<>1
|
|||
|---|---|---|---|
|
#18+
Про функции замечание в общем справедливое - если функция использует в качестве аргументов поля из текущей записи. Но дело в том, что использование условия OR тоже оптимизацию совсем не улучшает. И потом - человек задал вопрос как записи выбрать, про оптимизацию речи не шло - вполне возможно, что там еще какие-то условия в WHERE будут, опять же количество записей в таблице неизвестно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2001, 10:01 |
|
||
|
|
start [/forum/topic.php?fid=46&msg=32019266&tid=1824562]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
58ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
36ms |
get tp. blocked users: |
2ms |
| others: | 255ms |
| total: | 391ms |
| 0 / 0 |
