Home All Groups Group Topic Archive Search About
Author
11 May 2005 1:34 AM
Vince
I have many functions in my VB project and they all have a stereotypical
errorhandler routine (far from the best but stops the program from crashing
on errors)

Function Blah
on error goto ErrorDescription:


goto ex:
ErrorDescription:
msgbox (err.description & " was encountered....")
ex:
end function

Now, the software is being moved to another location where the network
connection is pretty pathetic and very often, this results in disconnection.
On these occasions, when the functions try to access the SQL Server, the
users get a "Connection failure" from my error handler (the recordset cannot
be opened because the network connection is broken). So, I thought it would
be best if I could try to write some code where the software would attempt
to recover itself on broken connections. Changing each function's
errorhandler is a lot of work (should have been done in the initial stages),
so I thought I would get a Timer to run every 10 seconds and do something
like:

on error goto errordescription:
if sqlconnection.state<>adstateconnected
    sqlconnection.open connectionstring
    msgbox "Attempted to recover"
endif
goto ex:
errordescription:
msgbox "could not recover. Will retry in 10 minutes"
ex:

When I do the "Attempted to recover" I want all the existing "Connection
failure messages" to be closed (they are, of course, modal message boxes).
Is it possible to close all the message boxes this way? Is my salvage
approach correct? I have only one connection to the SQL Server running
through the life of the software. Please comment.

Thanks,

Vince

Author
11 May 2005 1:57 AM
Randy Birch
If you're using VB6 you can define a function in a bas module called MsgBox
and VB will call that procedure instead of its built-in method, removing the
requirement to recode your error routines. You could then use the code from
either http://vbnet.mvps.org/code/hooks/messageboxhooktimer.htm or
http://vbnet.mvps.org/code/hooks/messageboxhooktimerapi.htm in this MsgBox
function which would allow you to set the messagbox to automatically close
itself once the period you specify has elapsed. This will remove the
requirement to try to find and close any other message boxes generated.

If you use this method in a routine and name it MsgBox, you can still invoke
the real message box if required by prefacing it with "VBA" ...

  VBA.MsgBox "the real deal"

But, I also have to comment on the use of message boxes in general. I too
was faced with this type of problem and instead opted for a writing the
error data to both a file (for later tracing) and to a listbox on the form
(e.g. on an "errors" tab). The only time I threw up a dialog was when the
network went down, because that required user intervention. Self-recovering
errors were simply logged to the file/list for review if required.

--

Randy Birch
MS MVP Visual Basic
http://vbnet.mvps.org/
----------------------------------------------------------------------------
Read. Decide. Sign the petition to Microsoft.
http://classicvb.org/petition/
----------------------------------------------------------------------------



Show quote
"Vince" <sd***@fsd.com> wrote in message
news:O3yFSmcVFHA.2420@TK2MSFTNGP12.phx.gbl...
:
: I have many functions in my VB project and they all have a stereotypical
: errorhandler routine (far from the best but stops the program from
crashing
: on errors)
:
: Function Blah
: on error goto ErrorDescription:
:
:
: goto ex:
: ErrorDescription:
: msgbox (err.description & " was encountered....")
: ex:
: end function
:
: Now, the software is being moved to another location where the network
: connection is pretty pathetic and very often, this results in
disconnection.
: On these occasions, when the functions try to access the SQL Server, the
: users get a "Connection failure" from my error handler (the recordset
cannot
: be opened because the network connection is broken). So, I thought it
would
: be best if I could try to write some code where the software would attempt
: to recover itself on broken connections. Changing each function's
: errorhandler is a lot of work (should have been done in the initial
stages),
: so I thought I would get a Timer to run every 10 seconds and do something
: like:
:
: on error goto errordescription:
: if sqlconnection.state<>adstateconnected
:    sqlconnection.open connectionstring
:    msgbox "Attempted to recover"
: endif
: goto ex:
: errordescription:
: msgbox "could not recover. Will retry in 10 minutes"
: ex:
:
: When I do the "Attempted to recover" I want all the existing "Connection
: failure messages" to be closed (they are, of course, modal message boxes).
: Is it possible to close all the message boxes this way? Is my salvage
: approach correct? I have only one connection to the SQL Server running
: through the life of the software. Please comment.
:
: Thanks,
:
: Vince
:
:
Author
11 May 2005 7:57 AM
Vince
Thanks a lot Randy. I'll try to use this Message box and modify it so that
it handles the error handler as well.

Vince

Show quote
"Randy Birch" <rgb_removet***@mvps.org> wrote in message
news:ucQwJzcVFHA.3076@TK2MSFTNGP12.phx.gbl...
> If you're using VB6 you can define a function in a bas module called
MsgBox
> and VB will call that procedure instead of its built-in method, removing
the
> requirement to recode your error routines. You could then use the code
from
> either http://vbnet.mvps.org/code/hooks/messageboxhooktimer.htm or
> http://vbnet.mvps.org/code/hooks/messageboxhooktimerapi.htm in this MsgBox
> function which would allow you to set the messagbox to automatically close
> itself once the period you specify has elapsed. This will remove the
> requirement to try to find and close any other message boxes generated.
>
> If you use this method in a routine and name it MsgBox, you can still
invoke
> the real message box if required by prefacing it with "VBA" ...
>
>   VBA.MsgBox "the real deal"
>
> But, I also have to comment on the use of message boxes in general. I too
> was faced with this type of problem and instead opted for a writing the
> error data to both a file (for later tracing) and to a listbox on the form
> (e.g. on an "errors" tab). The only time I threw up a dialog was when the
> network went down, because that required user intervention.
Self-recovering
> errors were simply logged to the file/list for review if required.
>
> --
>
> Randy Birch
> MS MVP Visual Basic
> http://vbnet.mvps.org/
> --------------------------------------------------------------------------
--
> Read. Decide. Sign the petition to Microsoft.
> http://classicvb.org/petition/
> --------------------------------------------------------------------------
--
>
>
>
> "Vince" <sd***@fsd.com> wrote in message
> news:O3yFSmcVFHA.2420@TK2MSFTNGP12.phx.gbl...
> :
> : I have many functions in my VB project and they all have a stereotypical
> : errorhandler routine (far from the best but stops the program from
> crashing
> : on errors)
> :
> : Function Blah
> : on error goto ErrorDescription:
> :
> :
> : goto ex:
> : ErrorDescription:
> : msgbox (err.description & " was encountered....")
> : ex:
> : end function
> :
> : Now, the software is being moved to another location where the network
> : connection is pretty pathetic and very often, this results in
> disconnection.
> : On these occasions, when the functions try to access the SQL Server, the
> : users get a "Connection failure" from my error handler (the recordset
> cannot
> : be opened because the network connection is broken). So, I thought it
> would
> : be best if I could try to write some code where the software would
attempt
> : to recover itself on broken connections. Changing each function's
> : errorhandler is a lot of work (should have been done in the initial
> stages),
> : so I thought I would get a Timer to run every 10 seconds and do
something
> : like:
> :
> : on error goto errordescription:
> : if sqlconnection.state<>adstateconnected
> :    sqlconnection.open connectionstring
> :    msgbox "Attempted to recover"
> : endif
> : goto ex:
> : errordescription:
> : msgbox "could not recover. Will retry in 10 minutes"
> : ex:
> :
> : When I do the "Attempted to recover" I want all the existing "Connection
> : failure messages" to be closed (they are, of course, modal message
boxes).
> : Is it possible to close all the message boxes this way? Is my salvage
> : approach correct? I have only one connection to the SQL Server running
> : through the life of the software. Please comment.
> :
> : Thanks,
> :
> : Vince
> :
> :
>

AddThis Social Bookmark Button