Question

I need to be able to test whether a System.Data.SqlClient.SqlException is due to a network error or not (.NET environment connecting to MS SQL Server). If it is, I can tell the user that there is a problem with his connection, whereas if it is not, it is most likely a bug in my code which is to be treated differently. Obviously, it is crucial not to have false positives (declare somehting a network problem when it is a bug).

In a related question over here it was suggested to extract the information from the exception text. This is ugly and difficult in my case, since the text is localized, and might be different depending on the environment.

For the time being, I examine the call stack for certain function calls, which (by experience) are associated with network problems:

System.Data.SqlClient.TdsParserStateObject.WritePacket
System.Data.SqlClient.TdsParserStateObject.ReadNetworkPacket
System.Net.Sockets.SocketException

However, none of these pops up if there is a timeout while executing, for instance, a SELECT query. So there, I would have to revert to checking whether “Timeout” appears in the exception message, which is ugly.

Does anyone out there have a better idea?

Answer 1

Parsing the error message and stack is the last thing you want to do.

SqlException comes with a collection of Errors.
By inspecting the SqlError.Number, SqlError.State and the SqlException inner exception you can make a good guess whether the exception is local (ie. network) or remote (ie. on server). Error numbers above 100 will be most likely reported by server. Error numbers -2, -1, 2, and 53 are know to be client side errors. Exceptions that contain an inner Win32Exception are also client side. MSDN contains this decision table to help.

As a side note: timeout is not a server error, there is no such concept as query timeout in SQL Server. Timeouts are triggered by your own application because of the default 30 seconds of SqlCommand.CommandTimeout.