B
BlockNinja
When I'm coding a function in VBA, I might run into a situation where I need
to use "On Error" in situations where an error WILL most definitely pop up.
Take this code for example:
....
while rs.EOF = false
Dim accobj as Access.Application
set accobj = new Access.Application
accobj.OpenCurrentDatabase "c:\blah.mdb", true
on error goto AnErrorOccured
accobj.Run "SomeProcedure", rs.fields("DateToUse").Value
accobj.Quit acQuitSaveAll
AnErrorOccured:
Err.Clear
set accobj = nothing
rs.MoveNext
wend
rs.Close
....
In this case above, I am using VBA in Access to open up some other Access
database and run a procedure. This NORMALLY works well, but in my real life
version of what I'm running, that "SomeProcedure" first checks to see if the
DateToUse is a weekend, if it is then it simply calls Application.Quit
because it doesn't need to process on the weekends. If the code in
SomeProcedure causes the new Access instance to quit, an error occurs. Even
though there's error handling in place, if I'm using this code to iterate
through several dates and process the Database (and in my case, Compact
afterwards each time, but I didn't want to clutter the example), on the
second time it sees this error I will get a Debugger message regardless of
the fact that I've cleared Error on the handler.
Long story short, I don't want my program execution to be stopped by errors,
even if there is (and there most definitely IS in this case) errors that will
happen. Does anyone know of a workaround for this?
One solution I've come to before when trying to provide a workaround before
was to put anything that might be erroneous in its own procedure. It seems
that when you do that, VBA will run it correctly and the error will be
handled. But this is a drain when you're trying to keep track of several
local variables and don't want to have to write a proc to pass all of the
variables off that you need just to run one or two lines of code.
If anyone knows of a faster solution where I can clear the Error fully and
make sure VBA doesn't cause a debugger message the second time an error
occurs, even if handled, then please let me know.
to use "On Error" in situations where an error WILL most definitely pop up.
Take this code for example:
....
while rs.EOF = false
Dim accobj as Access.Application
set accobj = new Access.Application
accobj.OpenCurrentDatabase "c:\blah.mdb", true
on error goto AnErrorOccured
accobj.Run "SomeProcedure", rs.fields("DateToUse").Value
accobj.Quit acQuitSaveAll
AnErrorOccured:
Err.Clear
set accobj = nothing
rs.MoveNext
wend
rs.Close
....
In this case above, I am using VBA in Access to open up some other Access
database and run a procedure. This NORMALLY works well, but in my real life
version of what I'm running, that "SomeProcedure" first checks to see if the
DateToUse is a weekend, if it is then it simply calls Application.Quit
because it doesn't need to process on the weekends. If the code in
SomeProcedure causes the new Access instance to quit, an error occurs. Even
though there's error handling in place, if I'm using this code to iterate
through several dates and process the Database (and in my case, Compact
afterwards each time, but I didn't want to clutter the example), on the
second time it sees this error I will get a Debugger message regardless of
the fact that I've cleared Error on the handler.
Long story short, I don't want my program execution to be stopped by errors,
even if there is (and there most definitely IS in this case) errors that will
happen. Does anyone know of a workaround for this?
One solution I've come to before when trying to provide a workaround before
was to put anything that might be erroneous in its own procedure. It seems
that when you do that, VBA will run it correctly and the error will be
handled. But this is a drain when you're trying to keep track of several
local variables and don't want to have to write a proc to pass all of the
variables off that you need just to run one or two lines of code.
If anyone knows of a faster solution where I can clear the Error fully and
make sure VBA doesn't cause a debugger message the second time an error
occurs, even if handled, then please let me know.