Global Recordset ?

[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?

 

[Brendan Reynolds]

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

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.

 

[Dirk Goldgar]

In

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?

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 -----

 

[Guest]

Thanks Brendan some good thoughts. I didn't want to start this without some
other thoughts.

 

[Guest]

I like the function method it makes alot of sence to me.

 

[Guest]

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.

 

[Dirk Goldgar]

In

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.

FWIW, I agree with Brendan, too. I do my error logging in an external
text file.

 

[Guest]

I don't log errors. That way, my boss can't prove it was I who screwed it up

 

[Dirk Goldgar]

In

If your errors are logged in an
external text file, you will still be able to read the text file and
determine the problem.

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