Error on cancel

dullster

Member
Local time
Today, 12:37
Joined
Mar 10, 2025
Messages
43
I have reports that are triggered off parameters. When the first parameter request comes up, if i cancel, I get "The OpenReport operation was canceled". How do i get it to cancel without the error?

This is my code

Private Sub btnPrintChecks_Click()
DoCmd.OpenReport "rptChkWrite", acViewPreview
End Sub
 
How do i get it to cancel without the error?
This is standard Access behavior. To stop it, you need to add error trapping to your procedure. Usually the error will be 2501 but sometimes you get a different error. If you get a different error, modify the first select case line to"
Case 2501, xxxx ' action cancelled
to add the second error code to the ignore case

Code:
Private Sub btnPrintChecks_Click()
On Error GoTo Proc_Error

DoCmd.OpenReport "rptChkWrite", acViewPreview

Proc_Exit:
   Exit Sub

Proc_Error:
    Select Case Err.Number
        Case 2501     'action cancelled
            Resume Next
        Case Else
            MsgBox "Error " & Err.Number & " (" & Err.Description & ") in procedure btnPrintChecks_Click of VBA Document Form_yourformname"
    End Select
    Resume Proc_Exit
    Resume
End Sub
 
That is not an error, merely an informative message.
 
I never use popup input parameters in queries. I prefer VBA to build filter criteria and apply to form or report. Get user input on form and validate before even attempting to open.

If I did need a dynamic parameter in query, I would reference a form control for input and still validate.

However, error handler tested and works.
 
Last edited:
I agree with June about the parms. It is far better to have the user enter them on the form where you can validate them and ensure they are there before you try to open the report. But, you should still include error trapping when your code opens another object regardless since there are other situations where your user will cancel the action and generate this error. If you want the user to see the error, you could leave it untrapped but I'm not recommending that.
 
I understand. This is an old Database originally design in a Dos Program. This is enter Parameters for check printing. It asks for the Start of the CheckNr and the Last CheckNr. It is when it asks for the first CheckNr and it is canceled instead of enter the CheckNr that it would through the message.
 
That PDF doesn't provide any new info and hardly addresses my questions.
 
We answered your question and even gave you the code to fix it. No need to make excuses why you can't fix the underlying problem. Just add the error handling code to trap the error.

Doesn't make sense to ask for the ending check number unless you are going to validate it. Why make the user have to count the number of records being selected for the check run? Also, are you validating that the entered check number is actually the next check number and hasn't skipped a check number or duplicated one. This would be so much easier/better if you did it before you opened the report. But it's your process.

If you are still using an old program, it must be useful to you. I have one client who is using the exact same executable I delivered in April 2009. That is probably a record. This is the 16th year with no code changes;) I've updated the app numerous times over the years but the client likes what he has and doesn't need any of the new features I've added.
 

Users who are viewing this thread

Back
Top Bottom