Trapping Error 2501

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Keith

    #1

    Trapping Error 2501

    I have the following code in the On No Data event of a report:

    ****
    On Error GoTo err_trap

    MsgBox "No items matching criteria.", vbInformation, gcApplication
    Cancel = True

    err_trap:
    If Err.Number = 2501 Then Exit Sub
    ****

    When the code pointer returns to the calling line:

    ****
    DoCmd.OpenRepor t Forms(gcFrmPrin t).lstReport.Co lumn(1), acViewPreview, ,
    strCriteria
    ****

    error 2501 is raised, even though I'm trapping for it both in the calling
    procedure and the report code.

    Am I missing something obvious? I'm guessing I am :o0

    Regards,
    Keith.


  • Justin Hoffman

    #2
    Re: Trapping Error 2501

    "Keith" <keith.wilby@ba eAWAYWITHITsyst ems.com> wrote in message
    news:42dcd10e$1 _1@glkas0286.gr eenlnk.net...[color=blue]
    >I have the following code in the On No Data event of a report:
    >
    > ****
    > On Error GoTo err_trap
    >
    > MsgBox "No items matching criteria.", vbInformation, gcApplication
    > Cancel = True
    >
    > err_trap:
    > If Err.Number = 2501 Then Exit Sub
    > ****
    >
    > When the code pointer returns to the calling line:
    >
    > ****
    > DoCmd.OpenRepor t Forms(gcFrmPrin t).lstReport.Co lumn(1), acViewPreview, ,
    > strCriteria
    > ****
    >
    > error 2501 is raised, even though I'm trapping for it both in the calling
    > procedure and the report code.
    >
    > Am I missing something obvious? I'm guessing I am :o0
    >
    > Regards,
    > Keith.[/color]



    Hi Keith
    I can't see the error handling in the other procedure - but there is no
    point looking for 2501 in two places. Here is a typical example where a
    command button opens a report. There is no error handling in the NoData
    event - you could put some in - but the place to catch 2501 is in the
    preview button's OnClick event.


    Private Sub Report_NoData(C ancel As Integer)
    MsgBox "No matching records"
    Cancel = True
    End Sub


    Private Sub cmdReport_Click ()

    On Error GoTo Err_Handler

    DoCmd.OpenRepor t "MyReport", acViewPreview

    Exit_Handler:
    Exit Sub

    Err_Handler:

    Select Case Err.Number

    Case 2501
    ' The report has been cancelled due to no data
    ' The report's coding shows the message,
    ' so no need for another one here.

    Case Else
    MsgBox Err.Description , vbExclamation, "Error No: " & Err.Number

    End Select

    Resume Exit_Handler

    End Sub


    Comment

    • Keith

      #3
      Re: Trapping Error 2501

      "Justin Hoffman" <j@b.com> wrote in message
      news:dbimoj$eng $1@nwrdmz02.dmz .ncs.ea.ibs-infra.bt.com...[color=blue]
      >
      > Hi Keith
      > I can't see the error handling in the other procedure - but there is no
      > point looking for 2501 in two places. Here is a typical example where a
      > command button opens a report. There is no error handling in the NoData
      > event - you could put some in - but the place to catch 2501 is in the
      > preview button's OnClick event.
      >[/color]
      Thanks Justin. Trapping in more that one place was an act of desperation
      ;-p

      This is what I have in the command button Click event:

      ****
      Private Sub cmdPreview_Clic k()

      On Error GoTo err_trap

      Dim strCriteria As String
      strCriteria = Me.OpenArgs & " = '" & Me.cboActionee & "'"
      If Me.ogrClosed <> 3 Then strCriteria = strCriteria & " And [Closed] = " &
      Me.ogrClosed
      Me.Visible = False
      DoCmd.OpenRepor t Forms(gcFrmPrin t).lstReport.Co lumn(1), acViewPreview, ,
      strCriteria
      DoCmd.Maximize

      err_trap:
      If Err.Number = 2501 Then Exit Sub

      End Sub
      ****

      I'll try your version in the meantime, but I'm wondering if some of the
      other stuff I'm doing is upsetting Access. I'm basically using the same
      filter form for two different reports. I'm using OpenArgs to pass the name
      of the field to filter on.

      Regards,
      Keith.


      Comment

      • Justin Hoffman

        #4
        Re: Trapping Error 2501

        "Keith" <keith.wilby@ba eAWAYWITHITsyst ems.com> wrote in message
        news:42dce584$1 _1@glkas0286.gr eenlnk.net...[color=blue]
        > "Justin Hoffman" <j@b.com> wrote in message
        > news:dbimoj$eng $1@nwrdmz02.dmz .ncs.ea.ibs-infra.bt.com...[color=green]
        >>
        >> Hi Keith
        >> I can't see the error handling in the other procedure - but there is no
        >> point looking for 2501 in two places. Here is a typical example where a
        >> command button opens a report. There is no error handling in the NoData
        >> event - you could put some in - but the place to catch 2501 is in the
        >> preview button's OnClick event.
        >>[/color]
        > Thanks Justin. Trapping in more that one place was an act of desperation
        > ;-p
        >
        > This is what I have in the command button Click event:
        >
        > ****
        > Private Sub cmdPreview_Clic k()
        >
        > On Error GoTo err_trap
        >
        > Dim strCriteria As String
        > strCriteria = Me.OpenArgs & " = '" & Me.cboActionee & "'"
        > If Me.ogrClosed <> 3 Then strCriteria = strCriteria & " And [Closed] = " &
        > Me.ogrClosed
        > Me.Visible = False
        > DoCmd.OpenRepor t Forms(gcFrmPrin t).lstReport.Co lumn(1), acViewPreview, ,
        > strCriteria
        > DoCmd.Maximize
        >
        > err_trap:
        > If Err.Number = 2501 Then Exit Sub
        >
        > End Sub
        > ****
        >
        > I'll try your version in the meantime, but I'm wondering if some of the
        > other stuff I'm doing is upsetting Access. I'm basically using the same
        > filter form for two different reports. I'm using OpenArgs to pass the
        > name of the field to filter on.
        >
        > Regards,
        > Keith.[/color]

        I can't see why this would not prevent the error 2501 occuring. Normally I
        have two labels Err_Handler and Exit_Handler so that the error handling code
        only runs if there was an error - whereas yours will always check if the
        error number is 2501 - even if no error occurred.
        The Exit_Handler label always has an exit sub as the last line and it
        enables me to clean up - often with an On Error Resume Next line at the
        beginning of the block. You may have your own style you are happy with, but
        you might like to consider the sort of approach shown below.

        The only other comment I would make is that you could slow down with the
        code a bit. For example:
        DoCmd.OpenRepor t Forms(gcFrmPrin t).lstReport.Co lumn(1), acViewPreview
        I might take the time to dim a variable for the report name and make sure I
        get a non-zero length string before I try to open the report, but I guess
        you will say that you can guarantee that gcFrmPrint will be open and
        lstReport.Colum n(1) will return a valid non-null value.


        Private Sub ShowRecordCount ()

        On Error GoTo Err_Handler

        Dim dbs As DAO.Database
        Dim rst As DAO.Recordset
        Dim strSQL As String

        Set dbs = CurrentDb

        strSQL = "SELECT COUNT(*) AS MyCount FROM tblMyTable"

        Set rst = dbs.OpenRecords et(strSQL, dbOpenForwardOn ly)

        If Not rst.EOF Then
        MsgBox rst.Fields("MyC ount") & " record(s)"
        End If

        Exit_Handler:
        On Error Resume Next
        rst.Close
        Set rst = Nothing
        Set dbs = Nothing
        Exit Sub

        Err_Handler:
        MsgBox Err.Description , vbExclamation, "Error No: " & Err.Number
        Resume Exit_Handler

        End Sub



        Comment

        • Keith

          #5
          Re: Trapping Error 2501

          "Justin Hoffman" <j@b.com> wrote in message
          news:dbit1n$15g $1@nwrdmz02.dmz .ncs.ea.ibs-infra.bt.com...[color=blue]
          >[/color]
          <snip>

          Many thanks again Justin, this may be the way to go :o)


          Comment

          Working...