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.
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
If Me.RecordSource <> "" Then
If IsNull(Me!EventID) Then
Me.Parent!Notes.Visible = False
Me.Parent!lblNotes.Visible = True
Me.Parent!Notes.Visible = True
Me.Parent!lblNotes.Visible = False
Me.Parent!Notes = Me!Notes
If Me!Locked = True Then
Me.AllowEdits = False
Me.AllowDeletions = False
Me.Parent.Form!Notes.Locked = True
Me.AllowEdits = True
Me.AllowDeletions = True
Me.Parent.Form!Notes.Locked = False
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.
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?
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.
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.