I have been facing this type of situation a dozen of times now and final want a permanent solution to it.
Problem
Cannot find Server PC's SQL Instance name on client PC.
Note:- I have installed SQL Express And Management Studio on both server and client
Server PC Name : M-PC
Server SQL Version : SQL Server 2008
Client PC Name : SHIVANG
Client SQL Version : SQL Server 2008
Client's PC SQL Server Screenshot
Solution that i have tried
1) Switching OFF firewall of both server and client PC completely (Domain, Private & Public)
2) Enabling and restarting the services : SQL Server and Browser Service
3) Enabling SQL Network Configuration settings
4) Also enabled "Allow remote connection" from SQL Server of both the PC
5) Networking between both the PC is perfect can access files through network of both the PC.
6) Even changed the IP configuration settings from obtain to static of both the PC (IP of Server is 192.168.1.41 and IP of client is 192.168.1.44)
7) I have completely uninstalled SQL Express and Management Studio from client and server and installed it again.
8) I also told my client to format the PC and then installed SQL Express and Management Studio. Still nothing.
9) They don't have any antivirus on any of the system (to block the connection)
FUN PART
Now the fun part here is while i was fiddling with the settings of client and server PC. Server PC started showing the client PC SQL Instance while client PC was still unable to find the server SQL Instance.
Below image is of Server PC's SQL Server
Below image is of Client PC's SQL Server
Here are the following settings i have been fiddling with:-
Changed IP from Obtain to Static of both the PC's (client and server)
Changed the Protocol : TCP/IP of SQL of both the PC's (client and server) [sorry i forgot to get the screenshots of it and was fiddling with it even more when the server PC stopped showing the client's PC SQL Instance]
Now i don't have a clue what to do next to solve this problem. Please help me if you can.
Thanks in advance
There are two levels of security that need to be changed in order to allow remote access.
SQL Server configuration: By default in Express, Developer, and
Enterprise Evaluation editions, connecting by the TCP/IP protocol is disabled. Enable this using SQL Server Configuration Manager.
Windows Firewall: While disabling the firewall entirely will work
for this component, doing so is not a security best-practice (nor is it
required). (Note: in this section, I assume a default
configuration. There are many settings that can be changed which
affect these steps slightly.)
There are two cases depending on the type of SQL Server instance you're connecting to:
Default instance (connect by computer name only). Add an allow
incoming rule either on TCP port 1433 or the database engine service
.
Named instance (connect by computer name + instance name). Add an
allow incoming rule on UDP port 1434 to access to the SQL Browser
service. Add an allow incoming rule on the database engine service.
Microsoft Step by Step Tutorial to Getting Started With DB
Sharing
Reference Stack
A Youtube Tutorial
I don't have a definitive answer for your inconsistent results but I do have some background information that may help you troubleshoot the problem.
SQL instances are enumerated using the SQL Server Resolution Protocol. This is an application layer protocol that uses UDP (not TCP) to send enumeration requests to servers on the local subnet and receive responses as shown in the communication flow for multi-instance discovery diagram. It is the SQL Server Browser services that listens on UDP port 1434 to handle enumeration requests.
Importantly, the UDP multicast protocol does not guarantee requests or responses are delivered. Consequently, loss may occur that can only be detected by a network trace. The SQL Server Resolution Protocol cannot know why no response was received; it could be because a server is down, network problem, firewall, SQL instance hidden, etc. Also UDP multicast requests are delivered only to devices on the local subnet so resolution is limited to those machines.
The PowerShell script below sends a UDP request to a specific host. You can run this to ensure the SQL Browser service responds with the expected information about the instance(s) on the host.
Function List-Instances($hostName)
{
Write-Host ("Retrieving information from SQL Server Browser service on host $HostName ...");
try
{
$udpClient = new-object Net.Sockets.UdpClient($HostName, 1434);
$bufferLength = 1;
$browserQueryMessage = new-object byte[] $bufferLength;
$browserQueryMessage[0] = 2; # list all instances
$bytesSent = $udpClient.Send($browserQueryMessage, $browserQueryMessage.Length);
$udpClient.Client.ReceiveTimeout = 10000;
$remoteEndPoint = new-object System.Net.IPEndPoint([System.Net.IPAddress]::Broadcast, 0);
$browserResponse = $udpClient.Receive([ref]$remoteEndPoint);
$payloadLength = $browserResponse.Length - 3;
$browserResponseString = [System.Text.ASCIIEncoding]::ASCII.GetString($browserResponse, 3, $payloadLength);
$browserResponseString
$elements = $browserResponseString.Split(";");
$elements
$namedInstancePort = "";
Write-host "SQL Browser Data:" -ForegroundColor Green;
$i = 0;
while($i -lt $elements.Length)
{
if([String]::IsNullOrEmpty($elements[$i]))
{
Write-Host "";
$i += 1;
}
else
{
Write-Host $(" " + $elements[$i] + "=" + $elements[$i+1]) -ForegroundColor Green;
$i += 2;
}
}
}
catch [Exception]
{
Write-host $("ERROR: " + $_.Exception.Message) -ForegroundColor Red;
}
}
# send request to SQL Brower service to enumerate all SQL instances running on specific host
List-Instances -hostName "SomeMachine";
In summary, successful resolution requires:
SQL Server Browser Service must be running
UDP port 1434 must be allowed through the firewall
The servers must be on the same subnet
No UDP packet loss
The servers respond in a timely manner
First, confirm the firewall settings. Install SQL Server Management Studio on a non-host LAN computer and check that you can connect using the IP address of the host. This may mean messing around with logon rights if SA is not enabled on the host server.
SQL Server Services > SQL Server Browser > Right Click > Properties > Service > Start Mode > Automatic.
SQL Server Services > SQL Server Browser > Right Click > Properties > Start
Open command prompt on host and/or LAN computer and execute:
sqlcmd -L
When you install SQL Express , you can't access it from network or remotely.
unless you configure the remote access option
1 - In Object Explorer, right-click a server and select Properties.
2 - Click the Connections node.
3 - Under Remote server connections, select or clear the Allow remote connections to this server check box.
Related
I like to consider myself a fairly smart individual with the superb ability to "Google" things. However, I am running into an issue that is driving me insane.
I am trying to connect to a Microsoft Azure SQL Server from my Alienware Laptop running Windows 10, over 5Ghz WiFi. It seems that something is blocking port 1433 (according to many Google results). Unfortunately, I have opened this port on my Nighthawk router, through Windows' Firewall (wf.msc) via inbound rule, and finally I have enabled port 1433 in Bitdefender for all applications. I still cannot connect to the SQL instance through SSMS (even tried DBeaver). I am getting TCP rejection messages "forcibly closed by remote host"
Here is the kicker. I can access my database on the same device through a vb.net application (though I believe this is a different port). The bottom line is, I know the credentials, I am the admin, but I cannot get port 1433 truly open.
What other steps can I try to remedy this situation? Any and all help will be appropriately credited.
You should open the port 1433 for outbound traffic from your local network instead of the inbound, also make sure you have added your client public IP address in your Azure SQL server firewall via the Azure Portal.
The full troubleshooting steps as below:
Ensure you have the appropriate ports open outbound from your local network or connection (typically port 1433)
Create a server-level firewall rule for your SQL database using the Azure portal.
Ensure you are using the correct server name and username for SSMS, the server name should be something like this: mynewserver20170313.database.windows.net.
Ensure you are using SQL Server Authentication
For SSMS the username format is username#servername
Ref: Use SQL Server Management Studio to connect and query data
I just installed SQL Server Express 2012 on my home server. I'm trying to connect to it from Visual Studio 2012 from my desktop PC, and repeatedly getting the well-known error:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
What I've done to try to fix this:
Run SQL Server Configuration Manager on the server and enable SQL Server Browser
Add a Windows Firewall exception on the server for TCP, ports 1433 and 1434 on the local subnet.
Verify that I have a login on the SQL Server instance for the user I'm logged in as on the desktop.
Verify that I'm using Windows Authentication on the SQL Server instance.
Repeatedly restart SQL Server and the whole dang server.
Pull all my hair out.
How can I get SQL Server 2012 Express to allow remote connections!?
Well, glad I asked. The solution I finally discovered was here:
How do I configure SQL Server Express to allow remote tcp/ip connections on port 1433?
Run SQL Server Configuration Manager.
Go to SQL Server Network Configuration > Protocols for SQLEXPRESS.
Make sure TCP/IP is enabled.
So far, so good, and entirely expected. But then:
Right-click on TCP/IP and select Properties.
Verify that, under IP2, the IP Address is set to the computer's IP address on the local subnet.
Scroll down to IPAll.
Make sure that TCP Dynamic Ports is blank. (Mine was set to some 5-digit port number.)
Make sure that TCP Port is set to 1433. (Mine was blank.)
(Also, if you follow these steps, it's not necessary to enable SQL Server Browser, and you only need to allow port 1433, not 1434.)
These extra five steps are something I can't remember ever having had to do in a previous version of SQL Server, Express or otherwise. They appear to have been necessary because I'm using a named instance (myservername\SQLEXPRESS) on the server instead of a default instance. See here:
Configure a Server to Listen on a Specific TCP Port (SQL Server Configuration Manager)
The correct way to connect to remote SQL Server (without opening UDP port 1434 and enabling SQL Server Browser) is to use ip and port instead of named instance.
Using ip and port instead of named instance is also safer, as it reduces the attack surface area.
Perhaps 2 pictures speak 2000 words...
This method uses the specified port (this is what most people want I believe)..
This method requires opening UDP port 1434 and SQL Server Browser running..
One More Thing...
Kyralessa provides great information but I have one other thing to add where I was stumped even after this article.
Under SQL Server Network Configuration > Protocols for Server > TCP/IP Enabled. Right Click TCP/IP and choose properties. Under the IP Addresses you need to set Enabled to Yes for each connection type that you are using.
You can use this to solve this issue:
Go to START > EXECUTE, and run CLICONFG.EXE.
The Named Pipes protocol will be first in the list.Demote it, and promote TCP/IP.
Test the application thoroughly.
I hope this help.
You can also set
Listen All to NO
in the protocol dialog then in the IP address IP1 (say)
set enabled to Yes,
define yr IP address,
set TCP Dynamic to Blank and
TCP port to 1433 (or whatever)
I had this problem recently. 2015 Aug
Solved by opening SQL Server Configuration Manager
SQL Server Network Configuration -> Protocols for SQLEXPRESS
Properties on TCP/IP -> IP Adresses tab
Everything stays default, only set IPALL: TCP Port to 1433
Can connect to with SQL Server Manager to machine: [hostaddress], 1433
Example:
This article helped me...
How to enable remote connections in SQL Server
Everything in SQL Server was configured, my issue was the firewall was blocking port 1433
On my installation of SQL Server 2012 Developer Edition, installed with default settings, I just had to load the SQL Server Configuration Manager -> SQL Server Network Configuration -> Protocols for MSSQLSERVER and change TCP/IP from Disabled to Enabled.
I had to add a firewall inbound port rule to open UDP port 1434. This is the one Sql Server Browser listens on.
I prefer way of "Rosdi Kasim" as that's doesn't require detail configuration on the IP.
I will definitely forget it again when I try to up another server again.
Keep It Simple Stupid (KISS) by simply enable the Sql Server Browser service, then add the \SQLEXPRESS behind the IP when you connect the server.
Direct using IP without "\SQLEXPRESS" was my point of failure as it doesn't use the default port.
Thanks.
I had to add port via Configuration Manager and add the port number in my sql connection [host]\[db instance name],1433
Note the , (comma) between instancename and port
I had the same issue with SQL Server 2014 locally installed named instance. Connecting using the FQDN\InstanceName would fail, while connecting using only my hostname\InstanceName worked. For example: connecting using mycomputername\sql2014 worked, but using mycomputername.mydomain.org\sql2014 did not. DNS resolved correctly, TCP/IP was enabled within SQL Configuration Manager, Windows Firewall rules added (and then turned the firewall off for testing to ensure it wasn't blocking anything), but none of those fixed the problem.
Finally, I had to start the "SQL Server Browser" service on the SQL Server and that fixed the connectivity issue.
I had never realized that the SQL Server Browser service actually assisted the SQL Server in making connections; I was under the impression that it simply helped populate the dropdowns when you clicked "browse for more" servers to connect to, but it actually helps align client requests with the correct port # to use, if the port # is not explicitly assigned (similar to how website bindings help alleviate the same issue on an IIS web server that hosts multiple websites).
This connect item is what gave me the clue about the SQL Server Browser service: https://connect.microsoft.com/SQLServer/feedback/details/589901/unable-to-connect-on-localhost-using-fqdn-machine-name
when you use wstst05\sqlexpress as a server name, the client code separates the machine name from the instance name and the wstst05 is
compared against the netbios name. I see no problem for them to match
and the connection is considered local. From there, we retrieve the
needed information WITHOUT contacting SQL Browser and connect to the
SQL instance via Shared Memory without any problem.
when you use wstst05.capatest.local\sqlexpress, the client code fails the comparison of the name (wstst05.capatest.local) to the
netbios name (wstst05) and considers the connection "remote". This is
by design and we will definitely consider improving this in the
future. Anyway, due to considering the connection remote and the fact
that it is a named instance, client decides that it needs to use
SQLBrowser for name resolution. It attempts to contact SQL Browser on
wstst05.capatest.local (UDP port 1434) and apparently that part fails.
Hence the error you get.
The reason for the "SQL Server Browser" service from TechNet (emphasis added by me): https://technet.microsoft.com/en-us/library/ms181087(v=sql.120).aspx
From the "Using SQL Server Browser" section:
If the SQL Server Browser service is not running, you are still able
to connect to SQL Server if you provide the correct port number or
named pipe. For instance, you can connect to the default instance of
SQL Server with TCP/IP if it is running on port 1433. However, if
the SQL Server Browser service is not running, the following
connections do not work:
Any component that tries to connect to a named instance without fully specifying all the parameters (such as the TCP/IP port or named
pipe).
Any component that generates or passes server\instance information that could later be used by other components to reconnect.
Connecting to a named instance without providing the port number or pipe.
DAC to a named instance or the default instance if not using TCP/IP port 1433.
The OLAP redirector service.
Enumerating servers in SQL Server Management Studio, Enterprise Manager, or Query Analyzer.
If you are using SQL Server in a client-server scenario (for example,
when your application is accessing SQL Server across a network), if
you stop or disable the SQL Server Browser service, you must assign a
specific port number to each instance and write your client
application code to always use that port number. This approach has the
following problems:
You must update and maintain client application code to ensure it is connecting to the proper port.
The port you choose for each instance may be used by another service or application on the server, causing the instance of SQL
Server to be unavailable.
And more info from the same article from the "How SQL Server Browser Works" section:
Because only one instance of SQL Server can use a port or pipe,
different port numbers and pipe names are assigned for named
instances, including SQL Server Express. By default, when
enabled, both named instances and SQL Server Express are configured to
use dynamic ports, that is, an available port is assigned when SQL
Server starts. If you want, a specific port can be assigned to an
instance of SQL Server. When connecting, clients can specify a
specific port; but if the port is dynamically assigned, the port
number can change anytime SQL Server is restarted, so the correct port
number is unknown to the client. ... When SQL Server clients request
SQL Server resources, the client network library sends a UDP message
to the server using port 1434. SQL Server Browser responds with the
TCP/IP port or named pipe of the requested instance. The network
library on the client application then completes the connection by
sending a request to the server using the port or named pipe of the
desired instance
I had a different problem from what all of the answers so far mentioned!
I should start off by saying that I had it in Visual Studio, and not SQL Server Express but the solution should be exactly the same.
Well, god, it's actually really simple and maybe a bit foolish.
When I tried to create a database and Visual Studio suggested the name of the SQL Server it gave me my Windows username and since it's actually the name of the server I went for it.
In reality it actually was my Windows username + \SQLEXPRESS. If you didn't change any settings this is probably yours too. If it works, stop reading; this is my answer. If it doesn't work maybe the name is different.
If, like me, you only had this problem in Visual Studio to check what is yours follow these steps:
Open SQL Server Management Studioicon.
If you don't see your server (docked to the left by default) press F8 or go to View -> Object Explorer.
Right click on the name of the server and choose Properties (The last item)
At the bottom left you can see your server's actual name under "Server" (not Connection, but above it).
This is the name of the server and this is what you should attempt to connect to! not what Visual Studio suggests!
One more thing to check is that you have spelled the named instance correctly!
This article is very helpful in troubleshooting connection problems: How to Troubleshoot Connecting to the SQL Server Database Engine
In my case the database was running on non standard port. Check that the port you are connecting is the same as the port the database is running on. If there are more instances of SQL server, check the correct one.
All you need to do is open the relevant port on the server's firewall.
Having problems connecting to SQL Server?
Try disconnecting firewall.
If you can connect with firewall disconnected, may be you miss some input rules like "sql service broker", add this input rules to your firewall:
"SQL ADMIN CONNECTION" TCP PORT 1434
"SQL ADMIN CONNECTION" UDP PORT 1434
"SQL ANALYSIS SERVICE" TCP PORT 2383
"SQL BROWSE ANALYSIS SERVICE" TCP PORT 2382
"SQL DEBUGGER/RPC" TCP PORT 135
"SQL SERVER" TCP PORT 1433 and others if you have dinamic ports
"SQL SERVICE BROKER" TCP PORT 4022
I have two Win 7 64 bit machines.
On the first one I have installed SQL Server 2008 R2 Express and have no trouble connecting via Management Studio with Windows Auth and also via SQL Auth with a user I set up on the database.
On the second machine I am trying to connect to the database on machine 1 using Management Studio. I'm trying SQL Auth. I therefore obviously also can't connect to it via connection string in my .NET Code
I can ping the first machine from the second.
Things I have tried include the following:
On the machine the database is installed make sure the firewall is allowing connection on Port 1433
Made sure SQL Server service is running
Made sure SQL Server Browser service is running
Created an exception for sqlbrowser.exe in the firewall
Enabled TCP/IP Protocol through SQL Configuration manager
Allowed Remote connections in SQL Server Management Studio
The error I get is:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections
This is the connection string I use in code
Data Source=xxx.xxx.xxx.xxx\sqlexpress;Initial Catalog=dbName;User Id=myUser;Password=myPassword;
This can be caused by a number of reasons but I'm glad my suggestion about checking firewall ports (rather than just allowing a one-way exception for SQL Browser) led you to the answer: the firewall wasn't allowing the correct port # through.
If i remember correctly SQL Server disables remote connections by default.
Please check whether remote connections are enabled and enable them if not:
RMB on Server in Management Studio Object Explorer -> Properties -> Connections -> Allow remote connections...
I just installed SQL Server Express 2012 on my home server. I'm trying to connect to it from Visual Studio 2012 from my desktop PC, and repeatedly getting the well-known error:
A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
What I've done to try to fix this:
Run SQL Server Configuration Manager on the server and enable SQL Server Browser
Add a Windows Firewall exception on the server for TCP, ports 1433 and 1434 on the local subnet.
Verify that I have a login on the SQL Server instance for the user I'm logged in as on the desktop.
Verify that I'm using Windows Authentication on the SQL Server instance.
Repeatedly restart SQL Server and the whole dang server.
Pull all my hair out.
How can I get SQL Server 2012 Express to allow remote connections!?
Well, glad I asked. The solution I finally discovered was here:
How do I configure SQL Server Express to allow remote tcp/ip connections on port 1433?
Run SQL Server Configuration Manager.
Go to SQL Server Network Configuration > Protocols for SQLEXPRESS.
Make sure TCP/IP is enabled.
So far, so good, and entirely expected. But then:
Right-click on TCP/IP and select Properties.
Verify that, under IP2, the IP Address is set to the computer's IP address on the local subnet.
Scroll down to IPAll.
Make sure that TCP Dynamic Ports is blank. (Mine was set to some 5-digit port number.)
Make sure that TCP Port is set to 1433. (Mine was blank.)
(Also, if you follow these steps, it's not necessary to enable SQL Server Browser, and you only need to allow port 1433, not 1434.)
These extra five steps are something I can't remember ever having had to do in a previous version of SQL Server, Express or otherwise. They appear to have been necessary because I'm using a named instance (myservername\SQLEXPRESS) on the server instead of a default instance. See here:
Configure a Server to Listen on a Specific TCP Port (SQL Server Configuration Manager)
The correct way to connect to remote SQL Server (without opening UDP port 1434 and enabling SQL Server Browser) is to use ip and port instead of named instance.
Using ip and port instead of named instance is also safer, as it reduces the attack surface area.
Perhaps 2 pictures speak 2000 words...
This method uses the specified port (this is what most people want I believe)..
This method requires opening UDP port 1434 and SQL Server Browser running..
One More Thing...
Kyralessa provides great information but I have one other thing to add where I was stumped even after this article.
Under SQL Server Network Configuration > Protocols for Server > TCP/IP Enabled. Right Click TCP/IP and choose properties. Under the IP Addresses you need to set Enabled to Yes for each connection type that you are using.
You can use this to solve this issue:
Go to START > EXECUTE, and run CLICONFG.EXE.
The Named Pipes protocol will be first in the list.Demote it, and promote TCP/IP.
Test the application thoroughly.
I hope this help.
You can also set
Listen All to NO
in the protocol dialog then in the IP address IP1 (say)
set enabled to Yes,
define yr IP address,
set TCP Dynamic to Blank and
TCP port to 1433 (or whatever)
I had this problem recently. 2015 Aug
Solved by opening SQL Server Configuration Manager
SQL Server Network Configuration -> Protocols for SQLEXPRESS
Properties on TCP/IP -> IP Adresses tab
Everything stays default, only set IPALL: TCP Port to 1433
Can connect to with SQL Server Manager to machine: [hostaddress], 1433
Example:
This article helped me...
How to enable remote connections in SQL Server
Everything in SQL Server was configured, my issue was the firewall was blocking port 1433
On my installation of SQL Server 2012 Developer Edition, installed with default settings, I just had to load the SQL Server Configuration Manager -> SQL Server Network Configuration -> Protocols for MSSQLSERVER and change TCP/IP from Disabled to Enabled.
I had to add a firewall inbound port rule to open UDP port 1434. This is the one Sql Server Browser listens on.
I prefer way of "Rosdi Kasim" as that's doesn't require detail configuration on the IP.
I will definitely forget it again when I try to up another server again.
Keep It Simple Stupid (KISS) by simply enable the Sql Server Browser service, then add the \SQLEXPRESS behind the IP when you connect the server.
Direct using IP without "\SQLEXPRESS" was my point of failure as it doesn't use the default port.
Thanks.
I had to add port via Configuration Manager and add the port number in my sql connection [host]\[db instance name],1433
Note the , (comma) between instancename and port
I had the same issue with SQL Server 2014 locally installed named instance. Connecting using the FQDN\InstanceName would fail, while connecting using only my hostname\InstanceName worked. For example: connecting using mycomputername\sql2014 worked, but using mycomputername.mydomain.org\sql2014 did not. DNS resolved correctly, TCP/IP was enabled within SQL Configuration Manager, Windows Firewall rules added (and then turned the firewall off for testing to ensure it wasn't blocking anything), but none of those fixed the problem.
Finally, I had to start the "SQL Server Browser" service on the SQL Server and that fixed the connectivity issue.
I had never realized that the SQL Server Browser service actually assisted the SQL Server in making connections; I was under the impression that it simply helped populate the dropdowns when you clicked "browse for more" servers to connect to, but it actually helps align client requests with the correct port # to use, if the port # is not explicitly assigned (similar to how website bindings help alleviate the same issue on an IIS web server that hosts multiple websites).
This connect item is what gave me the clue about the SQL Server Browser service: https://connect.microsoft.com/SQLServer/feedback/details/589901/unable-to-connect-on-localhost-using-fqdn-machine-name
when you use wstst05\sqlexpress as a server name, the client code separates the machine name from the instance name and the wstst05 is
compared against the netbios name. I see no problem for them to match
and the connection is considered local. From there, we retrieve the
needed information WITHOUT contacting SQL Browser and connect to the
SQL instance via Shared Memory without any problem.
when you use wstst05.capatest.local\sqlexpress, the client code fails the comparison of the name (wstst05.capatest.local) to the
netbios name (wstst05) and considers the connection "remote". This is
by design and we will definitely consider improving this in the
future. Anyway, due to considering the connection remote and the fact
that it is a named instance, client decides that it needs to use
SQLBrowser for name resolution. It attempts to contact SQL Browser on
wstst05.capatest.local (UDP port 1434) and apparently that part fails.
Hence the error you get.
The reason for the "SQL Server Browser" service from TechNet (emphasis added by me): https://technet.microsoft.com/en-us/library/ms181087(v=sql.120).aspx
From the "Using SQL Server Browser" section:
If the SQL Server Browser service is not running, you are still able
to connect to SQL Server if you provide the correct port number or
named pipe. For instance, you can connect to the default instance of
SQL Server with TCP/IP if it is running on port 1433. However, if
the SQL Server Browser service is not running, the following
connections do not work:
Any component that tries to connect to a named instance without fully specifying all the parameters (such as the TCP/IP port or named
pipe).
Any component that generates or passes server\instance information that could later be used by other components to reconnect.
Connecting to a named instance without providing the port number or pipe.
DAC to a named instance or the default instance if not using TCP/IP port 1433.
The OLAP redirector service.
Enumerating servers in SQL Server Management Studio, Enterprise Manager, or Query Analyzer.
If you are using SQL Server in a client-server scenario (for example,
when your application is accessing SQL Server across a network), if
you stop or disable the SQL Server Browser service, you must assign a
specific port number to each instance and write your client
application code to always use that port number. This approach has the
following problems:
You must update and maintain client application code to ensure it is connecting to the proper port.
The port you choose for each instance may be used by another service or application on the server, causing the instance of SQL
Server to be unavailable.
And more info from the same article from the "How SQL Server Browser Works" section:
Because only one instance of SQL Server can use a port or pipe,
different port numbers and pipe names are assigned for named
instances, including SQL Server Express. By default, when
enabled, both named instances and SQL Server Express are configured to
use dynamic ports, that is, an available port is assigned when SQL
Server starts. If you want, a specific port can be assigned to an
instance of SQL Server. When connecting, clients can specify a
specific port; but if the port is dynamically assigned, the port
number can change anytime SQL Server is restarted, so the correct port
number is unknown to the client. ... When SQL Server clients request
SQL Server resources, the client network library sends a UDP message
to the server using port 1434. SQL Server Browser responds with the
TCP/IP port or named pipe of the requested instance. The network
library on the client application then completes the connection by
sending a request to the server using the port or named pipe of the
desired instance
I had a different problem from what all of the answers so far mentioned!
I should start off by saying that I had it in Visual Studio, and not SQL Server Express but the solution should be exactly the same.
Well, god, it's actually really simple and maybe a bit foolish.
When I tried to create a database and Visual Studio suggested the name of the SQL Server it gave me my Windows username and since it's actually the name of the server I went for it.
In reality it actually was my Windows username + \SQLEXPRESS. If you didn't change any settings this is probably yours too. If it works, stop reading; this is my answer. If it doesn't work maybe the name is different.
If, like me, you only had this problem in Visual Studio to check what is yours follow these steps:
Open SQL Server Management Studioicon.
If you don't see your server (docked to the left by default) press F8 or go to View -> Object Explorer.
Right click on the name of the server and choose Properties (The last item)
At the bottom left you can see your server's actual name under "Server" (not Connection, but above it).
This is the name of the server and this is what you should attempt to connect to! not what Visual Studio suggests!
One more thing to check is that you have spelled the named instance correctly!
This article is very helpful in troubleshooting connection problems: How to Troubleshoot Connecting to the SQL Server Database Engine
In my case the database was running on non standard port. Check that the port you are connecting is the same as the port the database is running on. If there are more instances of SQL server, check the correct one.
All you need to do is open the relevant port on the server's firewall.
Having problems connecting to SQL Server?
Try disconnecting firewall.
If you can connect with firewall disconnected, may be you miss some input rules like "sql service broker", add this input rules to your firewall:
"SQL ADMIN CONNECTION" TCP PORT 1434
"SQL ADMIN CONNECTION" UDP PORT 1434
"SQL ANALYSIS SERVICE" TCP PORT 2383
"SQL BROWSE ANALYSIS SERVICE" TCP PORT 2382
"SQL DEBUGGER/RPC" TCP PORT 135
"SQL SERVER" TCP PORT 1433 and others if you have dinamic ports
"SQL SERVICE BROKER" TCP PORT 4022
I have a VB script which connects to a local SQL database to retrieve a value. The exact same script runs on about 100 servers, but a few of the servers produce this error:
[DBNETLIB][ConnectionOpen (PreLoginHandshake()).]General network error. Check your network documentation
Here is the code that runs:
Function GetPrimaryServerID
On Error Resume Next
Set objConnection = CreateObject("ADODB.Connection")
Set objRecordSet = CreateObject("ADODB.Recordset")
objConnection.Open "Provider=SQLOLEDB;Data Source=127.0.0.1;Initial Catalog=xxx;User ID=xxx;Password=xxx"
sqlquery = "SELECT ServerID FROM tblSettings"
objRecordSet.Open sqlquery,objConnection
objRecordSet.MoveFirst
GetPrimaryServerID = objRecordSet("ServerID")
objRecordSet.Close
objConnection.Close
End Function
The error occurs on the 5th line when trying to open the connection string. I'm confused as to why this script is working on nearly all servers and failing on only a handful. The database that they connect to is identical on every server in terms of structure, its only the data that changes.
Fixed the problem by doing the following:
Opened SQL Server Configuration Manager and went to Protocols for MSSQLSERVER -> TCP/IP. In the 'IP Addresses' tab, I noticed that IP2 which has address of 127.0.0.1 was active but not enabled. Changed to enabled and restarted SQL services. My VB script now successfully opens the connection to 127.0.0.1.
It could fail if the database is not configured to listen to TCP/IP traffic. The error "Named Pipes Provider, error: 0 - No process is on the other end of the pipe." points in that direction.
You can test that with:
telnet 127.0.0.1 1433
To configure where the server listens, use `SQL Server Network Utility" for SQL Server 2000, or "SQL Server Surface Area Configuration" for SQL Server 2005 and up.
It's not a database error, but a client tools or config error
The failing servers will probably:
have a different level of either SQL Server install /includes service pack)
are configured for Windows Authentication only
have an older MDAC (linked to SQL Service pack, OS Service pack etc)
Edit:
SQL Server SSL Encryption, server side, is described here. And in KB 316898 too
"Server side" requires only a server certificate and all connections are encrypted
"client side" requires client certs and is optional, and only for that client
Certain client libraries (notably MS JDBC) do not support this.
If I've guessed right, you'll have either client or server SSL encryption set based on the server (your script is acting as a client)
a blog entry too
It may also be mismatching calls to WSAStartup and WSACleanup. If you call WSACleanup too often then sockets stop working. And the SQL client will also break - which is usually the case for remote DB servers (as opposed to local instances accessed through named pipes etc.).
Try to disable the WPF and this should solve the problem (Control Panel -> Windows Firewall).
If not, then you can also stop the service for firewall (from Services.msc --> Windows personal firewall)