Для пробы создал запрос (с описанным/и с неописанным параметром). Значение параметра в набор записей не выводил. На отчет поместил поле с именем параметра. Если запрос возвращает данные - в поле параметра отражается его значение. Если нет - не отражается. (т.е. так, как если бы поле "параметра" выводилось в выходной набор данных).

ТАким образом, добавлять поля с параметрами в выходной набор нет необходимости. Но если необходимо возвращать параметр, даже если запрос не вернул ничего, надо, например, пополнить запрос юнионом с пустой записью (а выключить вывод пустой записи уже средствами отчета). Акс97

Такие дела.

2Roalex

"Легкое движение руки" стоит дополнительного поля на каждый параметр, в количестве записей, возвращаемых запросом. (т.е. памяти). А результат тот-же, что и без добавления параметров в выходной набор. Компромис: на этапе конструирования кинуть параметры в выходной набор. После "легких движений" - выкинуть. Но, если и для пустого набора надо выводить шапочку с параметрами, и тот и другой метод обломаются. (что заставляет подозревать, что невыводимый в набор данных параметр оказывается доступен из отчета каким-то кривым способом)

Надо к

SELECT f1, f2, f3 ... FROM table
WHERE f1=[param1];

приписать:

SELECT f1, f2, f3 ... FROM table
WHERE f1=[param1]
UNION
SELECT null,null,null ... FROM table;

тогда [param1], как показывает метод научного тыка, будет определен (независимо от его вывода в выходной набор). И его ([param1]) можно гордо насобачить на шапочку даже пустого отчета. В событии форматирования области данных при пустых полях вызвать отмену (Cancel=True). И все. (Можно еще играться сжимаемостью областью данных, но это не универсально).

:0) "этот случАй всех злее"
на такой случай:
...
SELECT null,null,null ... FROM MSysObjects;
- работает (в .md*) в любых условиях :0)