How do I cancel a report from opening?

[vwgolfman]

Hi,

Original post EDITED:

In a Report_Open method, if there are no records I would like to display a messagebox with a warning message (specified by me) and then Cancel the Report from opening. I don't want a messagebox popping up telling the user that the report opening has been cancelled.

How would I do these things and is the Report_Open method the correct place in which to do it?

The VBA in a Button_Click event (on a form) passes over the Queryname using OpenArgs:
DoCmd.OpenReport strReportName, acPreview, , , , strQueryName

...and the VBA in the Report_Open event sets the RecordSource:
Me.RecordSource = OpenArgs

Thank you for any help.

 

[boblarson]

There is a No Data event which you can give a message and set Cancel = True.

You still need to put an error handler in the code which tries to open the report and trap for it:

If Err.Number = 2501 Then 
   Exit Sub
End If

 

[ChrisO]

You should also be able to count the number of records the query produces and only open the Report if there are one or more.

 

[boblarson]

You should also be able to count the number of records the query produces and only open the Report if there are one or more.

Although technically it is more efficient to open the recordsource only ONCE, so responding to the raised error actually is faster and takes up less resources than querying the recordset twice if you do have records.

 

[ChrisO]

G’day Bob.

Maybe yes, maybe no…it would need testing.

Doing a DCount on a Query may be faster than opening a Report on an empty recordset.
We simply don’t know… it would need testing.

It is also generally considered better to prevent errors rather than simply handling them.

Now the OP has two methods.

 

[boblarson]

It is also generally considered better to prevent errors rather than simply handling them.

I don't find that to be necessarily true. There are many places where you purposely raise errors in programming - ON PURPOSE. It is a true programming method where you want to utilize the built-in benefits of the behavior of errors. So, it isn't something to be avoided, but it is something to go into knowing what you are doing and why.

 

[ChrisO]

>>I don't find that to be necessarily true.<<

That’s what I meant by >>generally considered<<

But >>Now the OP has two methods.<< is still true.

 

[vwgolfman]

Edit:

Thanks for your help guys, very much appreciated and all sorted now