Results 1 to 7 of 7
  1. #1
    Join Date
    Jun 2003
    Location
    Longmont, CO
    Posts
    258

    Unanswered: On Error Resume Next failing

    Hi guys,

    Access 2000 and 2002 to SQL 2K with the front end running on Server 2003 as a terminal server setup.

    The app test fine on all of our local machines in the test environment even when we set it up in a terminal server environment.

    HOWEVER, when running on the prod environment I'm finding instances where the code is stopping/breaking. No error message is returned but forms end up with #Name? in fields because their data source was never set and the pointer is still hung up as a hourglass. Otherwise the app is happy and will run.

    I've traced the problem back to instances of code that are run under 'On Error Resume Next'. However the app is terminating the code instead of 'resuming next'. As mentioned above, no error is displayed unless I'm walking the code in debug mode with break on all errors set. Then it trips the error handler and displays an appropriate message.

    The Options are NOT set to break on all errors.

    Any ideas? Has anyone run into this before?

    Thanks for your help!

  2. #2
    Join Date
    Jun 2004
    Location
    Terrapin Nation
    Posts
    205
    Thats a tough one. Is it possible that it is choking on the next line of code when it resumes? Are there global variable going out of scope? Can you paste some code or is it too much?

  3. #3
    Join Date
    Jun 2003
    Location
    Longmont, CO
    Posts
    258
    Here is one spot where it was failing. I added the "If Me.RecordSource <> "" Then" after the fact in order to prevent it from failing.

    Previously the app would stop running the code on the line "If IsNull(Me!EventID) Then". If I turned on 'Break on all errors' then it would give me an error saying that there was no such field as Me!EventID. But on all of my test computers the code ran without a hitch.


    Private Sub Form_Current()
    On Error Resume Next

    Call SubFormBorder(Me.Parent!EventsSub)

    If Me.RecordSource <> "" Then

    If IsNull(Me!EventID) Then
    Me.Parent!Notes.Visible = False
    Me.Parent!lblNotes.Visible = True
    Else
    Me.Parent!Notes.Visible = True
    Me.Parent!lblNotes.Visible = False
    Me.Parent!Notes = Me!Notes
    End If

    If Me!Locked = True Then
    Me.AllowEdits = False
    Me.AllowDeletions = False
    Me.Parent.Form!Notes.Locked = True
    Else
    Me.AllowEdits = True
    Me.AllowDeletions = True
    Me.Parent.Form!Notes.Locked = False
    End If

    End If


    End Sub

  4. #4
    Join Date
    Nov 2003
    Location
    Sussex, England
    Posts
    404

    Exclamation On error resume next

    Dunno If I really understand this one, but given the code you've shown, I'd suggest that on error resume next is not appropriate here. Rahter set up a label somewhere after the last end if, and resume there. Trouble is that won't solve the problem of it not picking up the me!EventID.

  5. #5
    Join Date
    Jun 2003
    Location
    Longmont, CO
    Posts
    258
    For the most part, I think the use of 'On Error Resume Next' is not the best option. Unfortunately I've inherited a gigantic Access app that uses it liberally and with conviction.

    For some reason one of our production locations has started having problems with On Error Resume Next.

    The code above gets run when another function sets this form as the subform of the parent. The recordsource needs to be dynamically set but you can't set the recordsource until the form is open. Hence, the first time this code runs, the recordsource is null.

    Currently, everywhere except on this one prod system, the code worked well with just On Error Resume Next. Now it requires the separate If statement. My concern is that 3 instances of the use of On Error Resume Next have now been identified as dysfunctional. What about the other 150 places it's used?

  6. #6
    Join Date
    Nov 2003
    Location
    Sussex, England
    Posts
    404

    Speed Ferret

    I'd suggest that you get hold of speed Ferret and use it to do some sort of find and replace for all those on error next bits of code. It may be that they have worked OK under certain conditions, but now those conditions don't apply. It certainly seems that it hasn't been structured too well from what you have said.


  7. #7
    Join Date
    Jun 2003
    Location
    Longmont, CO
    Posts
    258
    I'm afraid that this would be an absolute last-ditch solution. We're trying to spend as little time as possible propping up this Access app. Just removing the On Error Resume Next would create a couple month's worth of work at least trying to find and trap for all the errors that have previously not been handled.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •