Прежде всего, хочу заметить, что запросы с параметрами как класс в SQL в лоб не реализуются. Запросы с параметрами в MDB Access есть ничто иное как мало эффективная попытка их как-то сымитировать. На практике такие запросы использовать очень неудобно, если они должны быть источниками других запросов, которые в свою очередь являются источниками данных формы или отчета. Я говорю о возможностях задания значения параметров в вызывающем запросе - она просто отсутствует, остается только вводить значения параметров вручную в ответ на выскакивающие невпопад диалоговые окна. Идеология "черного ящика", которому на вход подается некоторая информация, а с выхода снимаются итоговые результаты, в SQL далеко не всегда по-человечески реализуется.
На практике функциональность запроса с параметрами в SQL реализуют многими способами. Каждый из них имеет свои плюсы и минусы.
Метод 1. Самый тупой и простой - сформировать на клиенте текст обычного непараметризованного запроса, в текст которого подставлены уже конкретные значения параметров. При изменении значения параметров формируется новый текст запроса и снова отправляется на сервер.
Метод 2. Использование хранимых процедур с параметрами. Один из наиболее существенных недостатков хранимой процедуры - неспособность возвращать обновляемый набор данных. В Access обычно это обходится использованием свойств формы Unique table и Resinc command. Их использование позволяет добавление и модификацию записей перенаправить в таблицу, в то время как отображается в форме записи, возвращаемые хранимой процедурой.
Метод 3. Использование inline-функций SQL2000 (в более ранних версиях они отсутствуют). Inline-функции с параметрами, возвращающая table, по своим возможностям и функциональности наиболее близки к понятию "черного ящика". Inline-функция также как и хранимая процедура возвращает необновляемый набор записей. Однако, ее можно использовать во View, который уже будет возвращать обновляемый набор записей (особенно, если у VIEW имеются instaed-триггеры). Правда, с ними несколько неудобно работать из Access-2000. ADP этой версии заточен под версию SQL 7.0, в которой нет UDF. Поэтому работа с UDF из ADP Access-2000 возможна только обходными методами (например, UDF пишутся в QA, задействуются во VIEW, а ADP работает только со VIEW).
Метод 4. Использование prepared-запросов. В коде VBA ADP это сводится к формированию объекта ADO Command с непустой коллекцией Parameters и заданием свойства prepared=true. В тексте SQL-команды вместо значения параметров указываются знаки вопроса. Например:
select * from AnyTable where Fld1=? and Fld2=?
Вместо знаков вопроса ADO автоматом подставляет значение первого и второго параметра. SQL-сервер при поступлении на него подобных запросов строит специфический план выполнения запроса, расчитанный заведомо на то, что параметры могут изменять значения. При поступлении на SQL-сервер повторно аналогичной команды с другими значениями параметров, при условии, что план ранее выполненного запроса еще находится в процедурном кэше, полная компиляция запроса не производится - в ранее подготовленный план подставляются новые значения параметров. Это позволяет сэкономить на многократной перекомпиляции схожих запросов, у которых изменяется только некоторая параметризованная часть.
Последний метод позволяет обращаться и из Access2000 к inline-функциям, если в тексте запроса пишется что-то вроде:
select * from MyFunc(?, ?)
Данный метод имеет свои удобства и неудобства. При задании подобных запросов в качестве источника данных формы необходимо оперировать свойством формы InputParameters (см. хелп).
Тем, кто переходит с MDB на ADP, следует обратить особое внимание, что VBA-функции, которые могли встраиваться в текст MDB-запросов, в ADP в текст запросов встраиваться не могут. Оно и понятно - ADP-запрос выполняется не в среде Access и VBA, а на SQL-сервере, которому про VBA ничего не известно.
Могут быть еше комбинации приведенных методов. Какой именно метод использовать - решать программисту.