As @David-W-Fenton suggested, use the WhereCondition with OpenReport instead of setting a Filter expression. Your WhereCondition can be the same string you were using for the Filter expression.
Also, if you give OpenReport an empty string as the WhereCondition, the effect is the same as no WhereCondition, so this (untested) code should work whether or not your getGlobal(1)
returns True.
Dim strWhereCondition As String
Dim strReport As String
strReport = "Test"
If (getGlobal(1) = True) Then
strWhereCondition = "VIP = True"
End If
Select Case Action
Case "View"
DoCmd.OpenReport strReport, acViewReport, , strWhereCondition
Case "PDF"
DoCmd.OpenReport strReport, acViewReport, , strWhereCondition
DoCmd.OutputTo acOutputReport, , acFormatPDF
Case "Print"
DoCmd.OpenReport strReport, acViewPreview, , strWhereCondition
End Select
Notice also that DoCmd.OutputTo, without an ObjectName argument, uses the active object ... which will be the "Test" report in this case.
Say you have a form named frmOne which has a command button with the code-behind as:
DoCmd.OpenReport "rptFoo"
And rptFoo uses qryFoo as its record source.
Enabling Track Name Autocorrect, then viewing the Object Dependencies for frmOne will not notify you that rptFoo is required by frmOne. It can however tell you qryFoo is required by rptFoo. Another issue is the object dependencies will not notify you that frmOne has been deprecated --- the current version is frmTwo.
Similarly, using Application.SaveAsText
to create text files for database objects, then grepping the text files would not tell you frmOne has been deprecated.
You could try a different approach to identify which of the database objects are required. Create a new database file. Import the startup form from the old database. Open the new database, and the form to identify the missing items it needs. Import those. Lather, rinse, repeat.
If the application isn't driven from a startup form, ask the users which forms and reports they use, then import those.
This approach will be tedious, and could take a few hours. However, I doubt the other approaches would be dramatically faster. On the plus side, you're pretty much guaranteed that you won't be importing unneeded objects into the new database. And if you miss anything which is needed, you can import that from the saved copy of the old database.
Best Answer
Open the report in design mode.
Press F4, you will be able to see the dropdown in the "Properties" window.
Choose "Report" from the dropdown. You will see the "Record Source" property below it.
That contains the query/table which is used to build the report.