Cannot trap 2501 error

[Dave]

I've read many threads on this error, and after hours of trying, I
can't seem to trap this run time error. Please excuse the length of
the following, but I think it's necessary under the circumstances.
This is the process...
A button on a report selector form opens a date picker form whose tag
property is set to the report name. Choose date parameters then click
'open report' button and pass report name to public function to open
that report. The report's 'no data' event passes the report name and
report caption to another public function that creates msgbox "There's
no data in report caption (or report name if there's no caption)".
This function has a docmd.CancelEvent line, otherwise the msgbox runs
twice because the nodata event runs twice. I have put 2501 error traps
in the sub that calls the open report function, the open report
function itself, the nodata event and the msgbox function, yet none of
them will catch it. Stepping through the code, I see the message is
generated at the last executed line of the nodata event. If I choose
'debug' it goes to the open report function and highlights the first
line. No doubt this cannot be resolved without a look at the code
(line spaces removed within to shorten). I'm so tired now that this is
bound to be something stupid I've overlooked. TIA!

Private Sub cmdOpenReport_Click()
Dim rpt As String
On Error GoTo errHandler 'does not trap cancel error
rpt = Me.tag
OpenReport (rpt)
errHandler:
If Err = 2501 Then Exit Sub
MsgBox "Error Number " & Err.Number & ": " & Err.Description
End Sub

Public Function OpenReport(rpt As String)
On Error GoTo errHandler 'does not trap cancel error
DoCmd.OpenReport (rpt), acViewPreview
Exit Function
errHandler:
If Err = 2501 Then Exit Function
MsgBox "Error " & Err.Number & ": " & Err.Description
End Function

Private Sub Report_Open(cancel As Integer)
DoCmd.Maximize
End Sub

Private Sub Report_NoData(cancel As Integer)
On Error GoTo errHandler 'does not trap cancel error
rptName = Me.Name
rptCaption = Me.Caption
NoData rptName, rptCaption
Exit Sub 'THIS IS THE LAST LINE EXECUTED BEFORE SYSTEM MESSAGE
errHandler:
If Err = 2501 Then Exit Sub
MsgBox "Error Number " & Err.Number & ": " & Err.Description
End Sub

Public Function NoData(rptName, rptCaption)
On Error GoTo errHandler 'does not trap cancel error
If rptCaption = vbNullString Then
rptCaption = rptName
End If
DoCmd.CancelEvent
MsgBox "There are no records in report """ & rptCaption & """.",
vbOKOnly, "No Records"
Exit Function
errHandler:
If Err = 2501 Then Exit Function
MsgBox "Error Number " & Err.Number & ": " & Err.Description
End Function

 

[tina]

Private Sub cmdOpenReport_Click()

Dim rpt As String
On Error GoTo errHandler 'does not trap cancel error
rpt = Me.tag
OpenReport (rpt)
errHandler:
If Err = 2501 Then Exit Sub
MsgBox "Error Number " & Err.Number & ": " & Err.Description
End Sub

try

If Err.Number = 2501 Then

also, you need an exit line to prevent the msgbox from running when the code
does *not* err. suggest a standard error handling setup, as

Exit_sub:
Exit Sub

errHandler:
If Err.Number = 2501 Then
Resume Exit_sub
Else
MsgBox "Error Number " & Err.Number & ": " & Err.Description
End If

you should only need the trap in the "open report" sub, since that's where
the error originates.

hth

 

[Dave]

try
If Err.Number = 2501 Then

[I tried that, makes no difference]

also, you need an exit line to prevent the msgbox from running when the code
does *not* err. suggest a standard error handling setup, as

[True enough. Never came up since choosing 'end' or 'debug' to the
message prompt caused this to not execute, so I didn't notice it.]

Exit_sub:
    Exit Sub

errHandler:
    If Err.Number = 2501 Then
        Resume Exit_sub
    Else
        MsgBox "Error Number " & Err.Number & ": " & Err.Description
    End If

[This should work and be a bit simpler:]
rpt = Me.tag
OpenReport (rpt)
Exit Sub
errHandler: etc, etc.

you should only need the trap in the "open report" sub, since that's where
the error originates.

I agree with your thinking. However, the error does not seem to be
generated here. Recall that I stated choosing to debug takes me to the
function called by this sub. Thanks for trying, but I implemented your
suggestion and it still does not work. How about it everyone? If I can
correct this, I can hand off the project; I've been re-assigned.
Thanks.

 

[tina]

comments inline.

try
If Err.Number = 2501 Then

[I tried that, makes no difference]

also, you need an exit line to prevent the msgbox from running when the code
does *not* err. suggest a standard error handling setup, as

[True enough. Never came up since choosing 'end' or 'debug' to the
message prompt caused this to not execute, so I didn't notice it.]

Exit_sub:
Exit Sub

errHandler:
If Err.Number = 2501 Then
Resume Exit_sub
Else
MsgBox "Error Number " & Err.Number & ": " & Err.Description
End If

[This should work and be a bit simpler:]
rpt = Me.tag
OpenReport (rpt)
Exit Sub
errHandler: etc, etc.

yes, that will work in this instance. what i posted was a *standard* error
handling setup, which supports simple handling, and also more complex
handling that requires certain actions occur before a procedure is exited
regardless of what error may occur. in some situations, i try to think of
inexperienced folks who might read the thread and not understand the
difference.

you should only need the trap in the "open report" sub, since that's where
the error originates.

[I agree with your thinking. However, the error does not seem to be
generated here. Recall that I stated choosing to debug takes me to the
function called by this sub. Thanks for trying, but I implemented your
suggestion and it still does not work.]

okay. did you try the trap *with* Err.Number in the open report function?

 

[Dave]

[I agree with your thinking. However, the error does not seem to be

generated here. Recall that I stated choosing to debug takes me to the
function called by this sub. Thanks for trying, but I implemented your
suggestion and it still does not work.]

okay. did you try the trap *with* Err.Number in the open report function?

Yes. Take another look at the first line of the first public function
code in the original post and you'll see it there.

I have solved the problem with another programmer's help and thought I
should reveal the solution here in case it happens to someone else. At
first, he asked if I had the "Break on all errors" option set, which I
did. Resetting this to "Break on unhandled errors" didn't solve the
problem, but I thought it was a great first thought.

The idea of public functions to open a report and handle the nodata
event was based on my desire to enable others to carry on creating
reports and simply assigning variables so they didn't have to re-
create the code for each open event and nodata event. However, as he
noted, the code behind the report was so small, it may as well be
replicated. The task of getting the report name and caption for a
message box was moved to the nodata sub, thereby eliminating a second
public function call. This solved the problem as the error became
trappable in the sub that called the report open function as you said
it should. Furthermore, he said that by not using a resume statement
in my error trapping, I could be causing memory leaks as the error
event may not be killed simply by exiting (like not setting an object
to nothing after it has been created). I'm now resuming to exitHere:
just before the exit sub or function line.
Thanks for your help!

 

[tina]

comments inline.

[I agree with your thinking. However, the error does not seem to be
generated here. Recall that I stated choosing to debug takes me to the
function called by this sub. Thanks for trying, but I implemented your
suggestion and it still does not work.]

okay. did you try the trap *with* Err.Number in the open report

function?
Yes. Take another look at the first line of the first public function
code in the original post and you'll see it there.

if you're referring to
Public Function OpenReport(rpt As String)
then i did see error handling in the posted code - but not Err.Number, just
Err.

I have solved the problem with another programmer's help and thought I
should reveal the solution here in case it happens to someone else.

oh, good, thanks.

At
first, he asked if I had the "Break on all errors" option set, which I
did. Resetting this to "Break on unhandled errors" didn't solve the
problem, but I thought it was a great first thought.

yes, good idea.

The idea of public functions to open a report and handle the nodata
event was based on my desire to enable others to carry on creating
reports and simply assigning variables so they didn't have to re-
create the code for each open event and nodata event. However, as he
noted, the code behind the report was so small, it may as well be
replicated. The task of getting the report name and caption for a
message box was moved to the nodata sub, thereby eliminating a second
public function call. This solved the problem as the error became
trappable in the sub that called the report open function as you said
it should. Furthermore, he said that by not using a resume statement
in my error trapping, I could be causing memory leaks as the error
event may not be killed simply by exiting (like not setting an object
to nothing after it has been created).

ah, there we go. i learned standard error trapping, but if i ever learned
the *why* of it (beyond the "mop-up" use i mentioned), i'd forgotten. thanks
for sharing that!

I'm now resuming to exitHere:
just before the exit sub or function line.
Thanks for your help!

well, you're welcome, such as it was, and thanks for yours as well!