Коллеги,
не могу понять, в чем дело. Элементарный запрос.
В MS SQL - все ок. А в Fireberd 1.5.1 выдает полную дурь.

Вот данные:
TABLE_ID VALUE_ID F_DATE ID
18 1 01.06.2005 1
18 2 02.06.2005 2
18 3 03.06.2005 3
18 4 04.06.2005 4
18 5 05.06.2005 5
18 6 06.06.2005 6
18 7 07.06.2005 7
18 8 08.06.2005 8
18 9 09.06.2005 9
18 10 10.06.2005 10

Вот запрос:
select * FROM d_recent
WHERE
table_id = 18 and
id not in (
select first 5 id from d_recent
where
table_id = 18
order by f_date
);

Запрос возвращает пустоту. А должен - 5 строк:
TABLE_ID VALUE_ID F_DATE ID
18 10 10.06.2005 10
18 9 09.06.2005 9
18 8 08.06.2005 8
18 7 07.06.2005 7
18 6 06.06.2005 6

Помогите, разобраться, кто тупит - я или Firebird

Ну, буду знать. Большое спасибо. Хотя, релиз ноутс по диагонали прочел, но такого именно не увидел.

Вообще-то, если инструкция недопустима, то она должна скорее выдавать сообщение об ошибке, чем молча вываливать неверный результат. Нечестно это. И это при том, что промежуточные релизы выходят относительно часто.
А что, ни одна релизнутая версия Firebird не выполнит такой запрос?

Переделал запрос со SKIP. Удобная штука.

Во всем MS виноват :) Это его T-SQL приучил к хорошей жизни, набил голову стереотипами. Вообще, как я понял, слишком многое из того, что на MSSQL удается делать одним select’ом, на Firebird приходится перекраивать на хранимых процедурах и UDF. Уф... как же это медленно пишется.

FreemanZAVА то, что в FB можно сделать на ХП в MS SQL не сделаешь вообще (или через ж.)
Что, например?
Да и «через ж.» - звучит как-то субъективно. Что считать «через ж.», а что - нет?

Select/SQL - это, грубо говоря, пользовательский инструмент, а ХП - программистский. Продвинутая СУБД обязана давать максимум возможностей по выборке и манипулированию данными без использования ХП. В частности, у пользователя может не быть прав на написание функций или ХП, а данные добыть необходимо.
Вот и придется сначала выбирать данные из Firebird, загружать их в MSSQL, а затем уже - крутить-вертеть ими. :)

Patriot
Да и не факт еще что достаточно сложный запрос оптимизатор MS SQLа раскрутит оптимально.

Да, не факт. Но далеко не всегда это актуально.
Вот мне, например, все, что сейчас нужно от СУБД - это полнофункциональный SQL, который не заставляет писать ХП на каждый писк Firebird.
Скажем так: оптимизация выборки должна быть опцией, на тот случай, когда это действительно необходимо. Оптимизация идет последними этапами, а разработка базового функционала - первыми.