2 Жмурик
Не понял, зачем? Adp или mdb?
Select * from sometable where Idsometable = 1 - поставляем это в RecordSource и не знаем бед.

К вопросу о параметрах

В переменную загоняйте, потом через openargs передавайте в отчёт - всё будет работать нормально.

В принципе, в конструкторе отчёта можно сразу прописать значение параметра в хранимой равное возвращаемому значению функции в аксесе, а в источнике данных вашу хранимую - в ссылке различные варианты действий описаны.

2 Жмурик
По ссылке можно прочитать, как работать с отчётами - ещё поиск по форуму, а наиболее распространённые способы решения я уже изложил выше...

2 Жмурик

Речь идет не об умении работать с Access, а о борьбе с ошибками в его реализации. Весь форум, где встречается слово Recordset я прошерстил полностью, прежде, чем задавать вопрос

По ссылке ходили? Там как раз пример работы с отчётами. Ну нельзя в аксесе программно задавать InputParameters в отчётах и точка.
Такой момент:
В конструкторе отчёта в RecordSource: [owner].mySuperSP, в InputParameters: @myparam varchar(8000)=mysuperfunc(), где mysuperfunc() string function.
Сохраняем отчёт. Теперь в хранимой процедуре делаем селект в какую-нибудь временную табличку количества знаков в @myparam - ну не верю я, что что-то обрезается. Не нашёл нигде ограничения по кол-ву символов в InputParameters. Более того, у нас передаётся строка SQL в ХП для динамического формирования запроса для отчёта, свои грабли - но так исторически сложилось в некоторых местах (оффтоп просто) - никогда ничего не обрезалось.
Ещё такой момент - вы упомянули, что через ADODB.Command всё работает, так значит и по вышеописанному тоже всё должно работать.

И желательно этот фильтр запоминать для каждого пользователя...
Так и запоминайте в таблице фильтров для пользователя, при изменении - сохраняйте последний фильтр. Не временная табличка:) Либо делайте ини файл на каждой машине либо в реестр (но это уже не для фильтров).

Или я (и задачи, стоящие передо мною) давно переросли его возможности?

Ну-ну:)