The theory goes that it's the SQL error number, eg. the server side ERROR_NUMBER()
. In other words, the first list.
However there are a number of exceptions reported by SqlClient that occur on the client side, not on the server side. A typical example would be an error like failure to connect to the server, since you did not connect there is no server side error to speak of. For example a bad server name (does not resolve in DNS), in such cases the InnerException
will point toward a Win32Exception
with NativeErrorCode
value of ERROR_BAD_NETPATH
. In this case 53, the OS system error code, will be reported as SqlException error number.
Other cases the error reported by the SqlClient is a socket error, like an abrupt disconnect. Again, there is no 'server side' error to speak of, and the SqlException will wrap an InnerException of type SocketException
(a subclass of Win32Error) with the NativeErrorCode
of one of the well known WSA error numbers, like WSAECONNRESET
. In this case the SqlException.ErrorNumber
will be 10054, but it's the 10054 from the WSA range, not the 10054 from the SQL Server errors range. I know...
So what are you supposed to do? Make sure you check the InnerException
, if it's a Win32Exception
then the ErrorNumber
is coming from a system error code (OS error). Otherwise it should be a SQL Server error number.
Oh, and then there is -1
... I think that is reported by SqlClient itself (eg. some internal state errors) but I'm not sure.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…