Recently I was troubleshooting a connectivity issue in a development environment from an application. The application was using the connection string as
“Provider=sqloledb;Data Source=myserver\instance1,1433;Network=DBMSSOCN;Initial Catalog=mydb;Integrated Security=SSPI;”
I was able to connect to the SQL SERVER from SSMS, however when connecting from an application it was throwing the error
[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied
This is very generic one and can happen due to many reasons like
(1) Account may not have access or password might be wrong
(2) Connection might be blocked by a firewall
(3) Since it is a named instance, the port might be different. In some cases it might be dynamic also, for which the SQL Server Browser service should be up and running.
Looking at the connection string, everything looked good except for the “Network”. I had no idea of what it is. Googling led me to this KB article from Microsoft which clearly explains what it is.
Basically when an application is trying to connect to SQL SERVER, if one protocol fails then it tries to connect with another protocol. Example, assuming TCP/IP is enabled as primary and Named Pipes as secondary. When an application tries to connect to SQL SERVER, it first tries with TCP/IP. If that did not succeed, it tries with Named Pipes. If that also fails, then only it throws the error.
However, we can force the application to use only one protocol and that is done by the “Network” keyword in the connection string. This article defines all the options available for “Network”.
In my case the option “DBMSSOCN” corresponds to TCP/IP and it was disabled in the development machine. Enabling it, using this article, fixed the issue.
