Retrieve the "WHERECondition" on report open event()

[rum23]

Is it possible to retreive the "WHERECondition" that is set in OpenReport()
command? Is so, how do I do this? I want to retrieve this on the report
OnOpen() event.


Thanks

 

[Steve Schapel]

Rum,

I've never tried it, but I think you could write it into the OpenArgs
argument of the OpenReport.

 

[Rick Brandt]

Is it possible to retreive the "WHERECondition" that is set in
OpenReport() command? Is so, how do I do this? I want to retrieve
this on the report OnOpen() event.


Thanks

It will be in the Report's filter property.

Me.Filter

 

[Allen Browne]

It will be in the Report's filter property.
Me.Filter

Rick's suggestion is the most obvious approach, but unfortunately is not
100% reliable.

The Filter property of a form or report may contain an old filter, even if
the filter is not applied. Therefore you need to test the FilterOn property
to see if it's a real filter or an artifact:
If Me.FilterOn Then MsgBox Me.Filter
That works perfectly in forms, but in reports Access does not always report
the FilterOn property correctly in Report_Open.

(I haven't tested this in A2007, but it was a problem in previous versions.)

 

[David W. Fenton]

Rick's suggestion is the most obvious approach, but unfortunately
is not 100% reliable.

The Filter property of a form or report may contain an old filter,
even if the filter is not applied.

Can that possibly be a problem for a report that was opened with
DoCmd.Openform and criteria passed as an argument to that command? I
thought the command worked by taking the argument passed, putting in
the Filter property (overwriting anything that might have been there
already) and turning FilterOn to True. If I'm right, then there's no
way what you describe could happen.

Therefore you need to test the FilterOn property
to see if it's a real filter or an artifact:
If Me.FilterOn Then MsgBox Me.Filter
That works perfectly in forms, but in reports Access does not
always report the FilterOn property correctly in Report_Open.

(I haven't tested this in A2007, but it was a problem in previous
versions.)

I think I'd want to write anything like this to work regardless of
whether the report was opened with a filter argument or not, so I'd
probably be checking anyway.

On the other hand, an awful lot of my reports are driven by
filtering that draws its values from a class module used for storing
the filter values, so that the WHERE clause gets written in the Open
event and assigned there. In that case, I have full control and can
always know what's going on.