Непоследователни резултати при проверка за нулеви стойности (Jet DAO срещу ACE DAO)

В програма VB6, осъществяваща достъп до MDB файл, се изпълнява следната SQL заявка:

> Select * FROM [table1] WHERE ([type] = 1 OR [type] = 2 OR [type] = 6)
> AND ([notes] = Null OR [notes] = '0') AND [date] >= 
> cvdate('09/03/2013') ORDER BY [date], [column2]

Ако се позова на Microsoft Access 14.0 Object Library в програмата, върнатият набор от записи има 0 реда.

Ако реферирам Microsoft DAO 3.51 Object Library, върнатият набор от записи има над 100 реда.

Каква е причината за тази разлика? Има ли разлика между начина, по който двата доставчика обработват теста за Null? Това критична промяна ли е за достъпа на ACE DAO до по-стари MDB файлове?


person CJ7    schedule 20.04.2013    source източник


Отговори (2)


WHERE ... [notes] = Null е нестандартен SQL. Нулево разпространение потенциално може да принуди всеки израз, включващ Null, да върне Null. Следователно изразът [notes] = Null (който сте възнамерявали да бъде булев израз) може много добре да върне Null, което не е нито True, нито False.

Начинът, по който процесорът за заявки обработва тази Null стойност може наистина да се различава от една база данни до друга: той може да интерпретира Null като False или може просто да игнорира резултата, или може да предизвика грешка. Обърнете внимание също, че нулевото разпространение може да свие цялата ви клауза WHERE до Null, ако...

(some other condition) AND (Null)

... се оценява на Null.

Стандартният SQL ще бъде ([notes] IS NULL), а еквивалентът на Jet/ACE ще бъде IsNull([notes]). И двете винаги ще връщат True или False.

person Gord Thompson    schedule 20.04.2013

DAO 3.51 е много остарял. Беше заменен от DAO 3.6 преди много години. Използвайте 3.6 вместо това и след това вижте дали тази версия на вашата заявка връща същите резултати както от DAO 3.6, така и от ACEDAO:

SELECT *
FROM [table1]
WHERE
        [type] IN (1,2,6)
    AND ([notes] Is Null OR [notes] = '0')
    AND [date] >= cvdate('09/03/2013')
ORDER BY [date], [column2];
person HansUp    schedule 16.10.2013