Передача параметра в событии открытия отчета в запрос параметра (Access 2007)

Question

Я хотел бы знать, есть ли способ установить параметры в запросе Access 2007 с помощью VBA. Я новичок в использовании VBA в Access, и мне было поручено добавить немного функциональности в существующее приложение.

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

Пользователь не хотел бы вводить идентификатор поставщика в форме ввода данных (поскольку форма уже отображает идентификатор поставщика), но на коммутаторе ему будет предложено ввести идентификатор поставщика.

Я застрял в том, как вызвать запрос отчета (в событии открытия отчета) и передать идентификатор поставщика из формы в качестве параметра. Я пытался некоторое время, и я не могу заставить что-либо работать правильно. Вот мой код, но я явно в замешательстве.

Private Sub Report_Open (Отменить как целое число)

Dim intSupplierCode As Integer

'Check to see if the data entry form is open
If CurrentProject.AllForms("frmExample").IsLoaded = True Then

    'Retrieve the SupplierID from the data entry form
    intSupplierCode = Forms![frmExample]![SupplierID]

    'Call the parameter query passing the SupplierID????
    DoCmd.OpenQuery "qryParams"


Else

    'Execute the parameter query as normal

    DoCmd.OpenQuery "qryParams"?????


End If

End Sub

Я пробовал Me.SupplierID = intSupplierCode, и хотя он компилируется, он запускается, когда запускается. А вот мой SQL-код для запроса параметров:

ПАРАМЕТРЫ [Введите поставщика] Long; ВЫБЕРИТЕ Suppliers.SupplierID, Suppliers.CompanyName, Suppliers.ContactName, Suppliers.ContactTitle ОТ Поставщиков WHERE (((Suppliers.SupplierID) = [Введите поставщика]));

Я знаю, что есть способы обойти эту проблему (и, возможно, также легкий путь), но, как я уже сказал, мой недостаток опыта в использовании Access и VBA осложняет ситуацию. Если бы кто-нибудь из вас мог помочь, это было бы здорово!

Answer 1

Здесь делается предложение на 100% УДАЛИТЬ параметр из запроса. Это не только решает вашу проблему, но и означает, что вы можете использовать запрос для кода, других форм и не разбить весь ваш дизайн, потому что одна глупая форма не открыта (отсюда ОЧЕНЬ причина вашего вопроса).

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

Итак, удалите параметр. Теперь в вашей форме, открывающей отчет, он может пропустить фильтр, и еще раз использовать то, что называется предложением «где». Это предложение «где» разработано в MS-доступе, чтобы решить проблему необходимости заранее знать, какие параметры и фильтры вам нужны. Это происходит во время выполнения, и, таким образом, МНОГИЕ РАЗНЫЕ формы могут вызывать и открывать этот отчет.

Теперь в форме, которая вызывает и открывает форму, вы идете:

Docmd.OpenReport "rptSuppliers",acViewPreview, , _
                "SupplierCode = " & me.SupplierCode

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

В случае НЕТ, когда предложение передается, и пользователь просто открывает форму, тогда никакие фильтры не будут использоваться, и никаких запросов не будет, и все записи будут показаны. Это, вероятно, ваш лучший подход.

Однако, если по какой-то странной причине вы по-прежнему считаете ДЕЙСТВИТЕЛЬНО необходимым иметь какое-то сообщение с отчетом, когда одна глупая форма просто не открывается, поместите следующий код в событие открытия форм.

If CurrentProject.AllForms("form1").IsLoaded = False Then
   Me.Filter = "SupplierID = " & InputBox("Enter Supplier ID")
   Me.FilterOn = True
End

Однако я бы действительно приложил усилия, чтобы избежать жесткого кодирования некоторых глупых имен форм в событии открытия отчетов. Мало того, что это означает жесткие зависимости кодирования какой-то глупой формы, которая теперь присоединена к отчету, но если вы позже скопируете этот отчет или даже скопируете оригинальную форму (или даже переименуете любой из этих объектов), вам придется зайдите в приложение и поищите, а теперь найдите места, которые вы, как разработчик, ввели зависимости. Такой подход может существенно увеличить затраты на обслуживание приложения и поэтому должен быть рекомендован.

Итак, здесь предлагается сбросить параметр запроса. Просто предоставьте форму или некоторую систему подсказок для запуска отчетов. Эти формы должны запрашивать у пользователя информацию, которую вы хотите отфильтровать. Или, как в вашем случае, эту информацию предоставляет связанная форма и ее текущая запись. Прелесть этой системы в том, что в отчете нет никакой депандансности.

Любая форма или даже любой код в будущем могут свободно передавать pramaeter, и он не будет ограничиваться SupplierID, но может быть любым типом фильтра или параметра, который вы пожелаете.

Имейте в виду, что, возможно, пользователь может не захотеть, чтобы эта форма была открыта, и, возможно, ему не нужна подсказка. С вашим дизайном и вопросом пользователь будет вынужден ввести значение параметра даже при запуске отчета без каких-либо открытых форм и не хочет, чтобы ему предлагали просмотреть все повторные записи в этом отчете.

Answer 2

Как я отмечал в недавнем сообщении , я никогда не склоняю жестко привязывать какие-либо параметры или контрольные ссылки к источникам записей отчетов или форм. Вместо этого я установил их во время выполнения. Самый простой способ - передать свойство WhereCondition в DoCmd.OpenForm / DoCmd.OpenReport:

DoCmd.OpenReport "MyReport", , , "[SupplierID]=" & Me!SupplierID

Это предполагает, что вы запускаете его из формы, в которой соответствующий ID поставщика уже присутствует в его источнике записей (т. Е. У вас есть запись с этим ID поставщика).

Более сложным является использование события OnOpen отчета для задания источника записей отчетов. Вот что я выделил в цитируемом посте выше . Но этот пример жестко связывает выбор с формой выбора, тогда как вы можете вместо этого предлагать различные наборы вариантов выбора в зависимости от контекста. Есть два способа справиться с этим:

1. если A2003 и более поздние версии, передать OpenArg (последний параметр DoCmd.OpenReport), чтобы сообщить событию OnOpen, что нужно сделать для сбора информации о том, к чему фильтровать.

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

Я подозреваю, что WhereCondition в DoCmd.OpenReport - ваше самое простое решение, но если вам нужны подробности о двух других, просто спросите.