Программная передача параметра в отчет о доступе
У меня уже есть Access MDB. Я добавляю командную кнопку в существующую форму, которая запускает существующий отчет. Внесенное изменение состоит в том, что этой кнопке необходимо передать параметр, содержащий идентификатор записи, о которой создается отчет - в настоящее время отчет запускается для каждой записи в MDB.
Я изменил запрос, по которому выполняется отчет, чтобы использовать параметр для значения идентификатора, так что теперь, когда кнопка нажата, Access запрашивает идентификатор записи для отчета, и отчет отображается так, как должен.
Однако, хоть убей, я не могу понять, как передать параметр в отчет для использования в запросе. Как я могу это сделать?
Ответы 5
Метод DoCmd.OpenReport имеет различные аргументы, одним из которых является оператор Where:
DoCmd.OpenReport"rptReport", acViewPreview,,"ID = " & Me.ID
Это
expression.OpenReport(ReportName, View, FilterName, WhereCondition, WindowMode, OpenArgs)
АГА! Это то, что я искал! Спасибо, Ремо.
Я использую Access 2003, и свойство «WhereCondition» на самом деле является четвертым параметром, поэтому в приведенном выше примере вам нужны только две запятые, а именно: DoCmd.OpenReport «rptReport», acViewPreview ,, «ID =» и Me.ID
Этот ответ следует улучшить, чтобы исключение параметра «FilterName» было менее неоднозначным. Т. е. поскольку большинство отчетов имеют существующий или встроенный запрос, в качестве «источника записи», «условия», это все, что необходимо передать в отчет. Параметр OpenArgs также является излишним при использовании для открытия отчета, поскольку для его реализации требуется гораздо больше усилий, и он чаще используется с DoCmd.OpenForm.
Мой общий подход к этому типу проблемы - сохранить критерии в базе данных, обычно в управляющей таблице с одной строкой. Затем, чтобы сослаться на ваши критерии, вы помещаете в скобки запрос, который возвращает одно значение из тех критериев, которые вы хотите. В вашем случае это будет примерно так:
(select reportID from control)
Преимущество этого метода в том, что контрольная таблица запоминает настройки для следующего запуска отчета. Конечно, ReportID будет привязан к полю в форме. Мне также нравится, что ваши запросы изолированы от форм; их можно запускать независимо от форм.
Почему все хотят все так усложнять, я не знаю.
сохраните источник записей вашего отчета без параметров.
как предлагает Remou, передайте критерии в соответствующий аргумент DoCmd.OpenReport.
Попытка сделать это любым другим способом будет вопросом сопротивления естественным методам выполнения задач в Access.
Предложение Where в docmd.openreport - это строка, которая использует тот же формат, что и предложение where в операторе SQL.
Причина, по которой параметризовать ваш запрос в docmd вместо RecordSource отчета, заключается в гибкости. Возможно, вам потребуется открыть отчет без каких-либо параметров / вернуть все записи или иметь возможность фильтровать по разным полям.
Я знаю, что это старый пост, но это заняло у меня немного времени. Ошибка была «Недопустимое использование parren», однако проблема заключалась в пробеле в имени поля. Я создавал отчет из базы данных, что кто-то сделал распространенную ошибку, пробелы.
Чтобы передать параметр в запрос через предложение where, когда в поле базы данных есть пробел, используйте этот пример:
DoCmd.OpenReport "rptByRegionalOffice", acViewPreview, , "[" & "Regional Office" & "]" & " = " & "'" & cmboOffices.Value & "'"
Если вы подумаете об этом, то увидите, что в результате будет получен where [Regional Office]='string value', как и следовало ожидать при доступе к sql.
Вы делаете очень много ненужных конкатенаций. Все, что вам действительно нужно, это: "[Regional Office] = '" & cmboOffices.Value & "'". И будьте осторожны, если [Региональный офис] может включать символ "'". В Access нормально использовать двойные кавычки для строк, поэтому: "[Regional Office] = " & Chr (34) & cmboOffices.Value & Chr (34)
Кроме того, вам следует прекратить использование пробелов в именах объектов (а также не буквенно-цифровых символов). Поскольку вы можете, многие люди делают это, но это потому, что они не обращают внимания на тот факт, что имя поля и его заголовок могут быть установлены отдельно, поэтому поле RegionalOffice может иметь свойство Caption «Региональный офис». Это означает, что когда вы перетаскиваете его в форму или отчет, оно автоматически будет иметь понятный для человека заголовок (с пробелами), а имя поля является дружественным к SQL (т. Е. Не требует скобок).
Я считаю, что это самый чистый способ сделать это.