Point of Failure in Procedures

[Bryan]

Does anyone know if there is a way to obtain the line where an error
occurred? Something like harnessing where 'Next' is in the Resume Next
statement would be great. Is this possible?

The reason I ask is because my test environment for a multiuser database
(~50 users) is the live environment, and I've periodically been logging
errors when the users exit and I can't figure out exactly where they're
occurring, or if it's even at the same line. I already know the module and
the procedure, although I suspect that the error is actually occurring in a
called procedure (with it's own error handler).

Please forgive me if this sounds absurd -- I am a not a programmer by trade,
nor does my job provide extra time (or pay!) for testing this thing.

Any help is appreciated.

Thanks,
Bryan

 

[Allen Browne]

Bryan, it's possible to put line numbers or labels into a problem procedure,
and use ERL to retrieve the label. This does slow your code down, but it can
help in pinpointing a troublespot.

Provided you use error handling in each procedure, you should not run into
the problem of the error occurring in a lower level procedure than where it
is being reported.

Breaking code into smaller chunks is desirable, though not always practical.

I'm not a fan of Resume Next. Where an error is likely, I prefer to break
the line off into another little function that has its own error handling.
For example if you're looping through controls that may not have a
ControlSource property, or table fields that may not have a Description
property, rather than Resume next in the main routine, and then testing
Err.Number:

Public Function HasProperty(obj As Object, strPropName As String) As Boolean
'Purpose: Return true if the object has the property.
Dim varDummy As Variant
On Error Resume Next
varDummy = obj.Properties(strPropName)
HasProperty = (Err.number = 0)
End Function

 

[Bryan]

Allen,

The abridged version of what's happening:

dbExit procedure does some things like closing forms, etc.
calls the Compact procedure, which
compacts and backs up the backend db
the dbExit procedure then stamps the time into a login/out table
dbExit then causes Acces to quit

I'll give you the long form if requested, i.e., the code.

Both error handlers call an ErrorLog procedure which logs the error into
another table. The ErrDescription field is required. The error being
logged is "Field 'tblErrorlog.ErrDescription' can't be a zero-length
string.", and the source procedure being passed is dbExit. However, on a
few occasions the temp file created during the Compact procedure was not
deleted, and the AdminLog (the one with the timestamps) table indicated
BU_FAIL (written only by the Compact proc), which tells me that the Compact
procedure failed, not dbExit.

I'm terribly confused about all of this, and thought logging the last line
completed might help pinpoint what's happening. What is ERL? How big is
the performance penalty if I do something like this?

Thanks again,
Bryan

 

[Allen Browne]

Is it possible you've missed an Exit Function in a routine, so the error
handler is being called without an error? That would explain Err.Description
being zero-length, and Err.Number would be zero.

As an example of ERL:

Sub TestERL()
On Error GoTo 2000

10 Dim i As Integer
20 For i = 32767 To 33000
30 Debug.Print i
40 Next

1000 Exit Sub

2000 MsgBox "Error " & Err.Number & " in line " & Erl
2010 Resume 1000
End Sub

 

[Bryan]

If I have missed an Exit Function, I'm not sure where -- because I'm only
getting the error maybe 5% of the time. Although it does make perfect
sense. I'll try using ERL to see if that pinpoints it.

Thanks very much for your help!

Bryan