Перекладываю один-к-одному из другого топика ( баги access ):

Geo:

Access 97 SP2 (только что видел, в остальных тот же запрос не проверял)

В запросах Access позволяет использовать обращение к формам:


Однако иногда при вызове более-менее сложного запроса посредством


иногда возникает ошибка "слишком мало параметров", хотя, если ту же строку, взятую из отладчика сохранить в виде запроса, она выполняется нормально.

Обойти ошибку можно так:

и

-----------------------------------------------
Serge Gavrilov
автор...иногда возникает ошибка "слишком мало параметров"

А разве не всегда?

-----------------------------------------------
Geo:
Гм.. Похоже, что всегда.
А может, это и не баг, а так и должно быть?

-----------------------------------------------
вадя
это связано , по-моему, с какими-то настройками,
или с сервиспаками. у меня прога рабочая.
на всех компах работает , но на новом компе отказалась, слишком....
запрос был с использованием в запросе полей с датами из формы.
у меня сложилось мнение, что в таком случае дату нада передавать в виде "mm\/dd\/yy" или "mm.dd.yy", т.е. в форме в поле данные должны отображаться в таком формате.
времени на тестирование не було, хотя на форуме это проскакивало.

-----------------------------------------------
Serge Gavrilov
GeoГм.. Похоже, что всегда.
А может, это и не баг, а так и должно быть?
Думаю да. Когда вы выполняете запрос, то access обеспечивает подстановку значений из форм, но когда запрос (инструкция SQL) используется для открытия Recordset или для Execute, то DAO (Jet) ничего не знают о формах (IMHO).

-----------------------------------------------
Victosha
Geo
<...>
Обойти ошибку можно так:

и


я бы в этом месте предпочел "обходить" явным заданием значения параметра.
Это должно существенно улучшить отклик и скорость перемещения по запросу.
В предположении, что они (параметры) все на формы ссылаются и запрос
сохранен, код для дао будет выглядеть примерно так:


для несохраненного запроса -

Set qry = CurrentDb.CreateQueryDef("","Select statement Where yourField=Forms!FormName.ControlName")

для адо - Command

-----------------------------------------------
Лох Позорный
Victoshaдля несохраненного запроса -

Set qry = CurrentDb.CreateQueryDef("","Select statement Where yourField=Forms!FormName.ControlName")
Для несохраненного запроса проще использовать конструкцию
Set rst = CurrentDb.OpenRecordset("Select ... Where ...=" & Forms![...][...])

Это так... к слову.

-----------------------------------------------
Victosha
Лох Позорный
<...>
Это так... к слову.

зарапартовался...

-----------------------------------------------
Victosha
а вот и не проще - & требует предположения о сравниваемогом поле - ставить
='" & Forms!... & "'
или не нать.
а Eval ничаво ни от кохо не просит.

Это я вспомнил - што за рапорт писал.
уж утро скоро, а работать все лениво.
шпать пойду. сегодня непер.


(с выражением лица)

-----------------------------------------------
Geo:
Извиняюсь, не подумамши написал - меня был проблема с выполнением запроса, текст которого живет в базе, и в нем другие способы не пройдут, у него свой where, а дописывать что-то в строку не сильно удобно. С вашего позволения, соберу-ка я это в один пост?

-----------------------------------------------
Лох Позорный
GeoС вашего позволения, соберу-ка я это в один пост?
Да по-хорошему это надо бы в отдельный топик выносить, ибо это вовсе даже не баг.

-----------------------------------------------
Geo:
Я бы все-таки сказал, что это "не совсем" баг. Функции же jet'овские запросы видят почему-то, во всяком случае, будучи запущенными из mdb-шки, содержащей эти функции. С другой стороны, в отдельный топик хорошо бы... Бат хау?

-----------------------------------------------
Victosha
GeoЯ бы все-таки сказал, что это "не совсем" баг. Функции же jet'овские запросы видят почему-то, во всяком случае, будучи запущенными из mdb-шки, содержащей эти функции. С другой стороны, в отдельный топик хорошо бы... Бат хау?

ну, уж ежели модератор не знает хау - то нихто не знает.
Можно просто почикать и усё.

Все-таки с параметром ситуация на мой взгляд интереснее, чем с функцией.
По поводу того, что запросы видят аксесовы функции.
В jet есть соответствующий апи, позволяющий вызывать "пользовательскую функцию" в контексте исполнения запроса jet (были тут вопросы от паскалистов на эту тему, хотя впору у них спрашивать - как это делать) -
Подозреваю, что в jet4 - это сидит дрывере доступа к mdb в виде
jet expression service type library (может и вру).
Похоже, часть этого апи заточена специально на вба испольнитель.
Честно говоря ни разу не встречал хоть каких-нибудь внятных описаний по использованию. Хотя, наверно, просто не искал.

Поскольку ф-ция внешняя, то план исполнения как правило оказывается сведенным к скану без использования индексов и прочих "продвинутых" технологий.

Применительно конкретно к акцесс эту (или похожую) ситуацию в "старых книжках" обсказывали примерно в следующих словах:
Мол акцесс-запрос живет как бы в двух видах - внутренний - понятный джету запрос, в котором никаких юзер-функций нет, и задача которого
вытащить набор данных (в некоторую темп-область), к которому уже будут применяться собственно акцессные функции.
Так или иначе, некая "двухфазность" исполнения для акцесса как будто бы есть. Ведь догадывается же он подставить параметр. Хотя это может быть не связано непосредственно с упомянутым апи.
В Адо эта ситуция вытягивается в то, что в формате 2002 и выше акцесс сам себе провайдер, а jet для него - data provider.

ПСЫ
а что лучше - значение параметра заполнять, или строку запроса склеивать - это всё-таки по месту решать...

В продолжение темы:
/topic/141320