Хорошо, а почему они работают так, как работают? Многие используют Access только для работы с таблицами данных. Им не нужно создавать формы и отчеты. Таким образом, если вы поместите поле [parm] в запрос, оно вас попросит, и вам не понадобится код. Итак, действительно удобная функция.
И, конечно, если вы создаете отчет и вам нужен быстрый и грязный способ запроса некоторых критериев, то опять же, супер удобно, и опять же, не нужно никакого кода или формнаписано.
И если вы создадите форму, вы можете поместить критерии в запрос, например, так:
select * from tblCustomers, где City = Forms! MyPromptForm! City
один разопять нет кода. И используя формы! Выражение, подобное приведенному выше, означает отсутствие запроса при выполнении запроса (или отчета, основанного на этом запросе).
Единственный реальный недостаток использования этих параметров - они не без труда делают их необязательными.
По мере того, как вы это узнаете, выкладывайте формы! Выражение в запросах может очень быстро запутаться. И такие запросы могут запрашивать вас, когда вы этого не хотите.
Еще хуже то, что теперь запрос «женат» и присоединен к этой ОДНОЙ форме (если вы используете выражения! Выражения для параметров). Часто у меня есть хороший запрос, который я мог бы использовать МНОГИЕ раз для разных отчетов, и часто даже один и тот же запрос мог использоваться для отчетов ... но потом кто-то приходит и вставляет выражение или параметр (ы), которые означают запросТОЛЬКО хорошо, когда эта форма открыта, или вы получаете неприятные подсказки для некоторого параметра, который вам сейчас не нуженИли вы хотите РАЗНЫЕ критерии для другого столбца.
Так что жесткое кодирование количества параметров в таком запросе ДЕЙСТВИТЕЛЬНО болезненно, не гибко и действительно начинает падать.
Итак, еслиу вас есть 5 полей со списком в форме, но пользователь выбирает ограничения только в 3 из полей со списком ... и хочет, чтобы другие 2 были проигнорированы?
Я мог бы написать еще 10 или страниц о том, почемупомещать выражения форм в запросы или вводить параметры некорректно (к тому же ... это делает запросы очень уродливыми и трудными для чтения. Кроме того, sql больше не является стандартным (он также не будет работать с серверными системами).
Итак, решение, используемое сейчас, состоит в том, чтобы просто взять значения из формы и создать собственное предложение where в коде. Таким образом, вы просто создаете отчеты (или формы) и присоединяете их к запросу,НЕТ ФОРМ! Условия помещаются в запрос. И SQL чист, без мусора.
Чтобы «отправить» условия в отчет (или форму), выmply используйте предложение "where". Именно поэтому в ms-access есть эта функция ... и она решает множество проблем ... и существенно сократит ваши затраты на разработку.
Посмотрите на следующие снимки экрана, чтобы понять, что я имею в виду:
Итак, у нас есть дата начала и окончания. И пользователь может выбрать 1 или несколько туров, а затем нажмите на кнопку просмотра отчета. Попытка иметь дело с простой и понятной формой «подсказки» для пользователя и ТОГДА попытка использовать запрос с параметрами-символами - это просто глупость.
Код, позволяющий работать с этими экранами выше, и запускать отчет с выбранными ограничениями, когдаВы нажимаете кнопку «печать» легко:
Или возьмите этот экран:
Так что в приведенном выше у нас есть комбополе для выбора торгового представителя.
Но вы можете оставить это поле пустым.
Таким образом, код для работы с выше будет работать так:
dim strWhere as string
'select sales rep combo
if isnull(cboSalesRep) = false then
strWhere = "SalesRep = " & cboSalesRep & ""
end if
' select "status" for the report
if isnull(lstStatus) = false then
if strWhere <> "" then
strWhere = strWhere " and "
end if
strWhere = strWhere & "Status = '" & litStatus & "'"
end if
Обратите внимание, как2-й список проверяется на значение. Вы можете добавить столько «много» условий, сколько хотите. Допустим, у нас есть флажок, чтобы включить только специальные клиенты. Мы можем добавить к нашему очень приятному экрану приглашения флажок
[x] Показывать только специальных клиентов
Код, который мы добавим, будет:
if chkSpeicalOnly = True then
if strWhere <> "" then
strWhere = strWhere " and "
endif
strWhere = strWhere & "SpecialCust = true"
end if
Конечно, каждая комбинация и элемент управления, которые мы добавляем на экран красивого отчета, занимают немного кода, но не более запутанно, чем построитель запросов ... и, таким образом, каждый запрос красив и чист и свободен от множества HIGHLY. необслуживаемые формы! выражения или «необязательные» параметры.
Кроме того, это означает, что вы можете повторно использовать один и тот же запрос для разных отчетов и не беспокоиться о какой-то форме, которая должна быть открыта или какая-то неприятная из синей подсказкидля параметра. Таким образом, немного больше кода устраняет проблему с беспорядочными запросами. Для меня это очень полезно при торговле.
Так что параметры бывают быстрыми и грязными. Но если ДЕЙСТВИТЕЛЬНО собираетесь начать создавать приличный пользовательский интерфейс и несколько хороших форм подсказок для отчетов? Дамп использования параметров - вы будете рады, что вы сделали. И вам нужно всего лишь перейти к ОДНОЙ позиции кода, добавить еще один блок кода для нового и дополнительного критерия. Вам не нужно изменять отчет, и вам также не нужно идти и изменять SQL. Таким образом, немного кода проходит ДОЛГОЙ способ решения этой проблемы.
В конце вашего кода у нас теперь есть допустимое предложение SQL where. Итак, теперь просто запустите отчет с этим:
Docmd.OpenReport "ReportName",acViewPreview,,strWhere
И выше также работает для поиска и запуска формы. Таким образом, форма может основываться на таких запросах, и, опять же, отсутствие запросов или параметров означает, что форма может использоваться для редактирования этих данных.
Таким образом, концепция фильтрации данных и запуска форм (или отчетов) может и должна бытьотделен от концепции некоторого запроса, который извлекает данные из таблицы. Со временем программное обеспечение изменится, и тогда начальник спросит, как насчет фильтра или запроса номера счета, но это опять-таки должно быть необязательным. Со временем ваши бизнес-правила изменятся. И вы часто можете применить этот фильтр к «многим» отчетам. Таким образом, в этой форме critea создается, но поле списка позволяет вам выбрать один из «многих» отчетов, и не все основаны на одном и том же SQL, но все они принимают тот же «фильтр», или лучше использовать терминпредложение where команды open report или form.
Выше пользователь может удерживать нажатой клавишу Ctrl для выбора 1 или2 или нажмите кнопку «Выбрать все». В этой форме пользователь фактически выбирает идентификатор автобусного тура для данного тура. И тогда они могут выбрать отчет в левом нижнем углу. Опять же, попытка получить вышеупомянутые множественные критерии просто не может работать с параметрами sql.
Я использую TourID = некоторое значение и Busid in (выбран список LIST OF).
один разопять же, вы можете просто передать это сложное предложение «where» в отчет - и это предложение where может даже иметь подзапрос или критерий Field in (LIST OF ID'S) (что в любом случае нельзя сделать с параметрами).