>Hi,
>
>I am monitoring through a log file when a user loses connection to the SQL Server and if it recovers. At the same time there is an error log system that logs all other general errors.
>
>I have noticed that yesterday, almost at the same time, twice, two users lost connection to the SQL Server and to the VM drive (where various meta files and the executable reside). I think that SQL Server connection was restored because the log showed that after attempt to recover, no more failure. But the application crashed based on the fact that it (the application) could not read the Shared drive (on the VM).
>
>Should I just discount this as a glitch with the network where the station completely lost connection to the network?
>
>Of course, I am thinking how can I recover - or attempt again - to have the application try connecting to the network, in order to restore the connection to the Share. The only way I possibly see it is by giving the application time (establishing a loop) whenever it tried to read a file or access a file on the Share. But there are SO many places where this is done, I can't think that it would be practical.
>
>Any suggestions? It was suggested already to write the error to the local drive but I don't want to go this route. Because then I will completely lose the knowledge of possible issues.
>
>TIA
>
>UPDATE. I am thinking of setting a loop to read any file on the SHARE, at the very top of the application. Then, if the program cannot read this "dummy" file, it can show a message to the user and close "gracefully." And the same at the end of the application, when the file on the Share is accessed. This way, also, to check if there is a connection. And if not, close gracefully.
>What do you think?

At a high level you make an explicit or implicit choice: Will my app assume the presence of a dependable network, or not? It's not unreasonable to answer Yes; even a stateless web app will fall over if the network connection goes down. In that case you don't need to take exceptional measures to mitigate unreliable networks.

In most cases the customer is responsible for the reliability of their environment. If your app crashes due to network issues, it's very helpful to track those instances:

- You can provide exact dates/times of issues so tech support can correlate that with other logs for troubleshooting purposes
- You have a response when someone inevitably points the finger at you

When you encounter a network issue the connection will be down. To handle or log these errors, these things you need must be local:

- Your error handler
- The location where you log information about the problem

To minimize changes to your app, you can:

- Wrap your ON ERROR or other error handlers such that if the network copy can't be reached, they can use a copy stored somewhere local. This can be avoided if your app is structured to use a launcher with a local copy of the network EXE, as the required handler will be guaranteed to be already present locally and not depend on network connectivity. Note that if you do choose to use a launcher, it can be configured to still try to write information to a network location by default

- TRY to write your error log information to the normal network location, but if that fails, write it somewhere local where you are guaranteed to have write access, such as the Windows temp files folder. You can inform your customers that information about network connection errors will be written to that folder. Better yet, you can e-mail those error logs to their IT staff and/or yourself. E-mail is worth TRYing because the error might be happening on a (say) VPN connection, but local LAN connectivity may still be OK so e-mail will still work

I'm not sure about your "Update" section. During normal operation, when your app requests a network operation, it will either work or it won't. I imagine your existing error handler already tries to shut down as gracefully as possible. If that involves trying to close network resources, those attempts should be wrapped in TRY...ENDTRY and avoid any possible error handling recursion. If you periodically check network connectivity outside your app's normal operation, in the event of a detected failure you will still have trouble closing network resources. You might get lucky from time to time and be able to prevent a user from filling in a form, only to not be able to save it later but if network problems are intermittent you certainly can't rely on that mechanism.

You at least need a robust way to log network errors. When your customer asks you "Why does the app keep crashing?" your best response is to be able to say "The network went down 37 times in the past month, on these dates and times, and your IT support already has the log files from those incidents".