Раньше работал с Sybase SQL Anywhere (помоему я уже это писал ;) и пользовался там отличной фичей:

select Table1.Col1, ... from (select ...) as Table1(Col1, Col2), ...

Очень хоцицца на Firebird такое поюзать. В принципе это реализуется с помощью view, но есть проблемы - create view требует обязательного завершения транзакции прежде чем его использовать, что является неприемлимым. Буду благодарен за ответ в виде подсказки как выйти из положения или может такую фичу включат в следующих релизах Firebird?

"в принципе, это реализуется иногда с помощью join..."

К сожалению есть запросы в которых join абсолютно бесполезен.

"а на sybase вы тоже налету вьюхи создавали?"

Там не надо этого делать! - он поддерживает подселекты прямо в секции from.

"Есть. Но не так уж часто они встречаются."

Если БД состоит из пяти таблиц то и не встречаются. У нас огромный проект (>500 таблиц, >70Mb исполняемого кода, >600 отчетов получаемых с помощью ~6000 запросов). Так вот если хотя бы 1% из этого требут такие подзапросы получаем капец.
Кроме того, эта фича на самом деле не отличается от уже реализованного механизма view. Просто надо научить его создавать (и уничтажать) временные view. Было бы круто!

А вообще хотелось бы перейти на Firebird, но из-за этих двух недостатков слишком много усилий потребуется.

Гмм, привести запросы не могу (боюсь любой из них заспамит весь форум, да и разобратьса в нем без базы и таких размеров запроса будет невозможно). Делать такие запросы мы начали не из-за хорошей жизни, и используем мы их только в случае крайней необходимости (когда основной запрос полностью выходит из под контроля из-за размеров и сложности для понимания).

И еще одна причина применение данных подзапросов:

Изначально база затачивалась под Sybase и репортер (чтоб он был здоров) был сделан на базе получения отчетов исключительно запросами (генерируемых автоматом исходя из дизайна и требуемых данных отчетов). Даже я бы сказал в результате на основе одного запроса полностью получается весь отчет. Переделать все наработки не представляется возможным. Я попытался сделать препарсер, разбивающий запрос на несколько частей (включая создание view), но пока все уперлось в стенку, из-за необходимости делать commit после обновления метаданных... Обидно, да!

"Такая проблема частично решается использованием ХП. Причем соединение с ХП идет через ее параметр."

Непонял. Как можно применять ХП без процедур?

К сожалению этим проблема не решается - абсолютно то-же самое получается с помощью View, а create procedure является также изменением метаданных базы и в запросе сработает только после commit.
Всем спасибо за помощь, видимо у нас в будующем ожидает тяжкая судьба переписывания запросов.

FreemanZAV, интересно и оригинально! Сейчас попробую (благо тестики имеются) и о результатах сообщу.
Спасибо.

Попробовал - сработало!!
Каковы ньюансы:
1. Геморрой с количеством параметров (и соотвественно полей в подзапросе - хотя конечно поможет создать процедуры на 1, 2, 3... параметров).
2. Геморрой с преобразованием типов параметров - либо точное совпадение либо сам туду-сюда преобразовывай. При преобразовании могут возникнуть проблемы с оптимизацией!
3. Оптимизация исполнения запроса. Есть подозрение, особенно при применении преобразования типов, может упасть скорость выполнения запроса относительно тех-же View (все таки View, как я понимаю механику, оптимизируется и выполняется не отдельно, а в совокупности с основным запросом - про процедуры ничего сказать немогу). Хотя радует то что скорость исполнения в двух вариантах моего теста была практически одинаковая!

Если кто выскажется по этим пункта (рекомендации, советы или знания в области схем оптимизации Firebird) было бы клево. Заранее благодарен.