Enable remote connections for SQL Server Express 2012 - sql-server-2012

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

Related

How can I identify what is blocking port 1433?

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

vb.net cannot run in network by other user [duplicate]

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

Can't connect to SQL Server using instance name

I installed SQL Server 2012 on Windows server 2012, I can connect to the server only if I write . in the server name field.
But I can't connect using the server name MSSQLSERVER.
I am trying to connect using SQL Server Management Studio from the same machine.
I checked that TCP/IP is enabled, IP2 is enabled, port 1433 is configured for all IPs, added an inbound rule for port 1433.
Also tried restarting both the SQL Server service and SQL Server browser service multiple times, but no luck.
Any ideas on what could be causing this problem?
Wow, this is an old post. Still I'm going try to answer this just in case someone else is wondering.
The Short Answer
MSSQLSERVER is typically not used as the name of a Server hosting the SQL Server Object (often referred to as SQL Server). Since you are using SSMS, you need simply define the name of the SQL Host--the actual NetBIOS name, or FQDN, or IP address of the host.
If no instance was created during installation
Server Name: ServerHostName
If an instance was created during installation
Server Name: ServerHostName\InstanceName
or IP address
Server Name: ###.###.###.###\InstanceName
If a port was defined other than the default port of 1433
Server Name: ServerHostName,####\InstanceName
The Long Answer
First a question. Is the MSSQLSERVER the actual NetBIOS name of your server? When talking about a SQL Server, it can be a little confusing at times as the name SQL Server is used to describe the host as well as the SQL Server Object (which is what most people are referring to in this context).
When using a tool like SSMS to connect to the SQL Server, you are first connecting to the host server, and once connected, you will connect to the SQL Object itself. The "." is not an object, or is not a valid SQL server name, unless you named your SQL server ".".
Regarding the instance, this is usually defined during the installation of the SQL Server (the object). Post installation, if you forget or simply do not know the name of the instance, the fastest way to determine what the instance name of your SQL server object is, is by checking system Services.
services.msc
Take a look at the SQL Services that are running. If you created a SQL instance during the installation of the SQL server object, then the instance name will be in (): i.e. (SQLInstance). On the same token, if you create multiple instances on the same server, then you will see multiple service names like,
Default Instance
SQL Server
With Instances
SQL Server (SQLInstance1)
SQL Server (SQLInstance2)
That should answer an issue where you can connect to one instance, but not another if one instance is running but the other is not.
If you did not create a SQL instance during installation, then the default SQL instance will always be MSSQLSERVER, and you will not need to define this in the Server Name spot of the SSMS.
I hope this helps.
It's a typical problem.
Just use cliconfg.exe to create alias with tcp/ip protocol.
If unsure do the same alias for 32 and 64 bit.
The 64 bit version is found in:
C:\Windows\System32
The 32 bit version is in:
C:\Windows\SysWOW64
In General tab enable TCP/IP.
In Alias, create a new alias, insert the name you prefer (with named istance) and select TCP/IP as network libraries.
As server name put the ip and 1433 as port. Don't leave "dynamicaly determine port" selected.
Source for cliconfg locations: http://sqlblog.com/blogs/tibor_karaszi/archive/2009/09/08/sql-client-config-32-and-64-bit.aspx
Try to enable the SQL Browser service.
The port number in SQL named instance is dynamic
SQL Brower uses UDP port 1434 to send the correct TCP port to the client.
If your SQL server instance is a default instance, you can login with the following as the Server name:
. (period)
LAPTOP-JDRDGF9T (the name of your PC)
localhost
127.0.0.1
If it on the other hand is a named instance, you login with localhost\<INSTANCE_NAME>, instance name normally being SQLEXPRESS.
You can Go to SQL Server Configuration manager >> SQL Server Network Configuration >> Protocol for MSSQLSERVER
OR
SQL Native Client configuration >> Client Protocols
In the right pane split page you will have to enable and disable the followings:
>> Shared Memory Enable this
>> Named Pipes Enable this
>> TCP/IP Enable this
>> VIA Disable this
Also, Check whether you have checked the Mixed mode authentication or not.

Unable to connect to SQL Express "Error: 26-Error Locating Server/Instance Specified)

I am at an loose end with one particular box that is running SQL Server 2008 R2 Express.
Windows Firewall is configured to allow inbound TCP & UDP 1433, 1434.
Windows Firewall is configured to allow outbound TCP & UDP on any port.
No other software AV/FW is currently running.
When I try to connect to xxx.xxx.xxx.xxx\sqlexpress, it times out with the following error:
TITLE: Connect to Server
Cannot connect to xxx.xxx.xxx.xxx\SQLEXPRESS.
ADDITIONAL INFORMATION:
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: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified) (Microsoft SQL Server, Error: -1)
I have checked that remote connections are allowed on the server.
I have confirmed TCP/IP is enabled and configured in SQL Server Configuration to allow connections on the external IP to 1433.
I have also used Wireshark from my local machine and I can see requests for 1433 UDP going to the remote server.
But using Wireshark on the remote server shows no inbound connection requests for 1433 UDP or anything from my external IP (with filtering to remote RDP from results).
This makes me think it is a firewall issue.
The server is hosted by an external company who have control over the PIX in front of our server.
I need to troubleshoot this as much as possible myself as the hosting company have no clue what they are doing.
I had a similar problem which was solved by going to the "SQL Server Configuration Manager" and making sure that the "SQL Server Browser" was configured to start automatically and was started.
I came across this solution in the answer of this forum post:
http://social.msdn.microsoft.com/Forums/en-US/sqlexpress/thread/8cdc71eb-6929-4ae8-a5a8-c1f461bd61b4/
I hope this helps somebody out there.
press windows+R open RUN Window
services.msc
find SQL Server(SQLEXPRESS) right click on that and start the service
then check
Go to SQL Server Configuration Manager > SQL Server Services > In Right Side window show all the servers which may stop. If you are using "SQLEXPRESS" then ,
Right click on SQL Server(SQLEXPRESS) and start. After try to connect server... I had same problem but I resolved by these steps.
Here is a simple method to troubleshoot connection issues:
Create an empty file called test.udl using a text editor
Double click the file test.udl, then specify your connection properties
Hit the "Test Connection" button.
I recently encountered the same issue however I am using Windows 10 Technical Preview Build 10041 and SQL Server 2014 (Advanced).
Follow the same advice from above:
In particular, my problem was that I did not enable the TCP/IP in Sql
Server Configuration Manager->SQL Server Network
Configuration->Protocols for SQLEXPRESS.
Once you open it, you have to go to the IP Addresses tab and for me,
changing IPAll to TCP port 1433 and deleting the TCP Dynamic Ports
value worked.
Follow the other steps to make sure 1433 is listening (Use netstat -an
to make sure 0.0.0.0:1433 is LISTENING.), and that you can telnet to
the port from the client machine.
Finally, I second the suggestion to remove the \SQLEXPRESS from the
connection.
AND ----> That last line is important! It looks like to be Windows 10 specific; remove \SQLEXPRESS from your connection string. What was frusting was that SQL Management Studio connects just fine using either connection string (full or short), however Visual Studio only accepted the connection string without the \SQLEXPRESS.
The active firewall on the server might be causing this. You can try to (temporarily) turn it off and see if it resolves the issue.
If it is indeed caused by the firewall, you should allegedly be able to resolve it by adding an inbound rule for TCP port 1433 set to allowed, but I personally haven't been able to connect this way.
I had a Same Problem but i solved by Restarting the browser service in SQL CONFIGURATION MANAGER and removing \SQLEXPRESS from the instance name in the connection window.
It's security all about. Make sure you have double check your firewall (windows and anti virus) in some cases when you disabled av firewall and restart your computer, automatically windows firewall is active and it's still block your application. Hope this is helpful ..
Could you post the connection string you're using that's giving you trouble?
You might need to add the port number to the Data Source value, as omitting it can also produce SQL Error 26.
E.g.: Data Source=ServerHostName\SQLServerInstanceName,1433
If you have done anything but in spite of all couldn't connecting?!!
In my case i have changed connection part splitting port "," instead of this ":"
The corresponding TCP port or pipe name is not specified in the connection string (such as Srv1\SQL2008, 1433).
This issue also confused me a few days, after the IT guy changed some security settings on the SQL Server.
I have an EntityFramework for the Web application and for a desktop application.
After I changed some settings on the SQL Server, the Web application comeback to work, but the desktop still facing issue. But I used the same connection string for both applications, it make no sense one is working but the other doesn't.
Then I searched a lot until I found someone saying here it is needed to add port number 1433 after the $ServerName\$DatabaseInstanceName,1433.
After I added it, the exception became:
System.Data.SqlClient.SqlException: Login failed for user
'domain\name-PC$'
Then I found this link. It says to add Trusted_Connection=False;.
The whole connection string should be like:
data source=XXXXX\SQLSERVER,1433;initial catalog=XXXDB;user id=UserID;password=PWD;Trusted_Connection=False;MultipleActiveResultSets=True;
Hope this answer will help the ones out off Generic exception:
Error: 26-Error Locating Server/Instance Specified
Have you Disabled the VIA setting in the SQL configuration manager? If not, do disable it first (if VIA is enabled, you cannot get connected) and yes TCP must be enabled. Give it a try and it should be working fine.
Make the changes only for that's particular instance name.
Cheers!
I found this url to be very useful:
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/2cdcab2e-ea49-4fd5-b2b8-13824ab4619b/help-server-not-listening-on-1433
In particular, my problem was that I did not enable the TCP/IP in Sql Server Configuration Manager->SQL Server Network Configuration->Protocols for SQLEXPRESS.
Once you open it, you have to go to the IP Addresses tab and for me, changing IPAll to TCP port 1433 and deleting the TCP Dynamic Ports value worked.
Follow the other steps to make sure 1433 is listening (Use netstat -an to make sure 0.0.0.0:1433 is LISTENING.), and that you can telnet to the port from the client machine.
Finally, I second the suggestion to remove the \SQLEXPRESS from the connection.
EDIT: I should note I am using SQL Server 2014 Express.
This really Works .. i had verified lot of sites and finally got the answer
This may occurs when the master.mdf or the mastlog.ldf gets corrupt . In order to solve the issue goto the following path
C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL , there you will find a folder ” Template Data ” , copy the master.mdf and mastlog.ldf and replace it in
C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\DATA folder .
Thats it . Now start the MS SQL service and you are done .
While there can be many reasons for this error - In my case it was pretty simple which I overlooked for a while. I was using server IP address along with instance name for Server as -
<add name="MyDBConnection"
connectionString="Persist Security Info=False;User ID=sa;Password=xxx;Database=MyDB;Server=nn.nn.n.nn\SQLInstance01; Connection Timeout=180" providerName="System.Data.SqlClient"/>
Correct connection string will look something like this (note this one doesn't have SQL Server instance name)
<add name="MyDBConnection"
connectionString="Persist Security Info=False;User ID=sa;Password=xxx;Database=MyDB;Server=nn.nn.n.nn; Connection Timeout=180" providerName="System.Data.SqlClient"/>
HTH.
In my case, I Installed SQL Express 2012 and the problem raise after I reboot my PC. I solved so:
I go to Services -> SQL Server (SQLEXPRESS) and I see that was stopped. I started and It's say an login error.
In properties, Tab Log On, I change it to Local System account , then I can start the SQL service.
Then to test it, I go to SQL Server Management Studio and I connect to .\SQLEXPRESS and it works!
I had a similar problem which was solved by going to the "SQL Server Configuration Manager" and making sure that the "SQL Server Browser" was configured to start automatically and was started.
it works for me
I got a similar problem with sql server , I have tried every thing but does not connect to database engine & it shows error:26.
First check if the database engine is running or not. by going into
configuration manager. start > sql server >sql server configuration
manager. On the right pane you should see the sql server (mss .. )
should be running state with a green indication.
IF the database engine is not running, simply uninstall sql
server / format your system if possible and then download sql
server 2012 and management studio. from
https://www.microsoft.com/en-ca/download/details.aspx?id=29062
Install server first, make sure to add server on installation phase
by clicking add server and then install management studio.
All you need to do is to go to the control panel > Computer Management > Services
and manually start the SQL express or SQL server.
It worked for me.
Good luck.

How to connect to SQL Server from another computer?

I want to connect from home using SQL Server 2005 to another PC.
I had a look on the msd...but before connecting it says I should connect to another computer
using the computer management and it didn't work out....I can only connect to computers from my workgroup?
Thanks,
Luisa
Disclamer
This is just some additional information that might help anyone. I want to make it abundantly clear that what I am describing here is possibly:
A. not 100% correct and
B. not safe in terms of network security.
I am not a DBA, but every time I find myself setting up a SQL Server (Express or Full) for testing or what not I run into the connectivity issue. The solution I am describing is more for the person who is just trying to get their job done - consult someone who is knowledgeable in this field when setting up a production server.
For SQL Server 2008 R2 this is what I end up doing:
Make sure everything is squared away like in this
tutorial which is the same tutorial posted above as a solution by "Dani" as the selected answer to this question.
Check and/or set, your firewall settings for the computer that is hosting the SQL Server. If you are using a Windows Server 2008 R2 then use the Server Manager, go to Configuration and then look at "Windows Firewall with Advanced Security". If you are using Windows 7 then go to Control Panel and search for "Firewall" click on "Allow a program through Windows Firewall".
Create an inbound rule for port TCP 1433 - allow the connection
Create an outbound rule for port TCP 1433 - allow the connection
When you are finished with the firewall settings you are going to want to check one more thing. Open up the "SQL Server Configuration Manager" locate: SQL Server Network Configuration - Protocols for SQLEXPRESS (or equivalent) - TCP/IP
Double click on TCP/IP
Click on the IP Addresses tab
Under IP1 set the TCP Port to 1433 if it hasn't been already
Under IP All set the TCP Port to 1433 if it hasn't been already
Restart SQL Server and SQL Browser (do both just to be on the safe side)
Usually after I do what I mentioned above I don't have a problem anymore. Here is a screenshot of what to look for - for that last step:
Again, if someone with more information about this topic sees a red flag please correct me.
If you want to connect to SQL server remotly you need to use a software - like Sql Server Management studio.
The computers doesn't need to be on the same network - but they must be able to connect each other using a communication protocol like tcp/ip, and the server must be set up to support incoming connection of the type you choose.
if you want to connect to another computer (to browse files ?) you use other tools, and not sql server (you can map a drive and access it through there ect...)
To Enable SQL connection using tcp/ip read this article:
For Sql Express: express
For Sql 2008: 2008
Make sure you enable access through the machine firewall as well.
You might need to install either SSMS or Toad on the machine your using to connect to the server. both you can download from their's company web site.
all of above answers would help you but you have to add three ports in the firewall of PC on which SQL Server is installed.
Add new TCP Local port in Windows firewall at port no. 1434
Add new program for SQL Server and select sql server.exe
Path: C:\ProgramFiles\Microsoft SQL
Server\MSSQL10.MSSQLSERVER\MSSQL\Binn\sqlservr.exe
Add new program for SQL Browser and select sqlbrowser.exe
Path: C:\ProgramFiles\Microsoft SQL Server\90\Shared\sqlbrowser.exe
I'll edit my previous answer based on further info supplied. You can clearely ping the remote computer as you can use terminal services.
I've a feeling that port 1433 is being blocked by a firewall, hence your trouble. See TCP Ports Needed for Communication to SQL Server Through a Firewall by Microsoft.
Try using this application to ping your servers ip address and port 1433.
tcping your.server.ip.address 1433
And see if you get a "Port is open" response from tcping.
Ok, next to try is to check SQL Server. RDP onto the SQL Server computer. Start SSMS. Connect to the database. In object explorer (usually docked on the left) right click on the server and click properties.
alt text http://www.hicrest.net/server_prop_menu.jpg
Goto the Connections settings and make sure "Allow remote connections to this server" is ticket.
alt text http://www.hicrest.net/server_properties.jpg
Here is the link ... You must read it.