Global Recordset ?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I want to create a global record set so I can track error into a error table.
Can you do that?

If so where would you do it?
 
I want to create a global record set so I can track error into a error
table.
Can you do that?

If so where would you do it?

--
Thanks,

JSY
MTTrader
Click to expand...


Well yes, you can, by declaring it using the Public keyword in a standard
module (not a form, report, or other class module). I can't think of any
advantage that you would gain by doing so, though. If I wanted to log errors
in a table (I prefer to log them in a text file) I would use a public
function that accepted the information about the error that I wanted to
record, opened the recordset, logged the error, and closed the recordset.
The function would be global, the recordset would not.
 
In
MTTrader said:
I want to create a global record set so I can track error into a
error table. Can you do that?

If so where would you do it?
Click to expand...

You can do it, but I don't recommend it. You'd need to declare the
recordset at module level in a standard module, and find some
approporiate database events to open it and to close it. Opening it
would not be much of a problem, because you could always have a logging
function that checks whether the recordeet is open, and opens it if it
isn't.

Closing it is another matter. There have been problems in the past
where unclosed recordsets have kept Access from fully closing, due to
dangling object references. I don't know if those problems have been
fully resolved or not. So you really want to make sure that all
recordsets are closed when you exit Access, which means catching the
many different ways that Access can be closed. Also, global variables
are reset in the event of an unhandled error, so if you have such an
error, your recordset could go poof!

One possibility workaround for this, if you really want to pursue this
idea, is to use a hidden form bound to your error-tracking table.
Access is pretty good about handling forms that happen to be open when
Access is closed.

However, I don't see any real point in keeping a recordset open all the
time for this purpose. Why not have an error-logging function that just
builds and executes a SQL statement on the fly? Along these lines:

'----- start of air code -----
Public Function LogError( _
ErrNumber As Long, _
ErrDescription As String, _
ErrSource As String) _
As Long

On Error GoTo ErrHandler

Const Q As String = """"
Const QQ As String = """"""

CurrentDb.Execute _
"INSERT INTO ErrorLog " & _
"(ErrNumber, ErrDescription, ErrSource) " & _
"VALUES(" & _
ErrNumber & ", " & _
Q & Replace(ErrDescription, Q, QQ) & Q & ", " & _
Q & Replace(ErrSource, Q, QQ) & Q & _
")", _
dbFailOnError

Exit_Point:
Exit Function

ErrHandler:
LogError = Err.Number
MsgBox _
"Unable to log error '" & ErrDescription & _
"' due to Access error " & Err.Number & _
": " & Err.Description, _
vbExclamation, _
"Unable to Log Error"
Resume Exit_Point

End Function
'----- end of air code -----
 
Thanks Brendan some good thoughts. I didn't want to start this without some
other thoughts.
 
The advantage of Brendon's idea is that if your database becomes seriously
corrupt as the result of some error, you may not be able to determine what
the error was. If your errors are logged in an external text file, you will
still be able to read the text file and determine the problem.
 
In
Klatuu said:
The advantage of Brendon's idea is that if your database becomes
seriously corrupt as the result of some error, you may not be able to
determine what the error was. If your errors are logged in an
external text file, you will still be able to read the text file and
determine the problem.
Click to expand...

FWIW, I agree with Brendan, too. I do my error logging in an external
text file.
 
In
Klatuu said:
If your errors are logged in an
external text file, you will still be able to read the text file and
determine the problem.
Click to expand...

And your clients can e-mail you the log file for remote debugging.
 
Back
Top