I have 4 different named instances of SQL Server 2005 on a single server (for testing purposes). There is no default instance on the server.
Because I will eventually need to allow communication to these instances across the firewall, I have set the ports of each instance statically listening on all IPs for the server.
Edit: TCP/IP, Shared Memory, and Named Pipes are all enabled. VIA is disabled. The ports are statically set for All IPs on the TCP/IP protocol, and each named instance is using a separate port.
I also have SQLBrowser service running, and all instances are configured to allow remote connections.
One instance is set to the default port (1433), and it works fine.
The other instances, however, exhibit very strange behavior. When I connect to them using the Sql Server Management Studio within the network (so I'm not even crossing the firewall yet), the studio connects without complaining. However, as soon as I try to expand the Database list for the instance, or refresh the instance, or pretty much anything else, I get the following error:
TITLE: Microsoft SQL Server Management Studio
Failed to retrieve data for this request. (Microsoft.SqlServer.SmoEnum)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&LinkId=20476
ADDITIONAL INFORMATION:
Failed to connect to server . (Microsoft.SqlServer.ConnectionInfo)
A connection was successfully established with the server, but then an error occurred during the login process. (provider: Named Pipes Provider, error: 0 - No process is on the other end of the pipe.) (Microsoft SQL Server, Error: 233)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&EvtSrc=MSSQLServer&EvtID=233&LinkId=20476
The first thing to do would be to try
adding the prefix np: or tcp: (for
either Named Pipes or TCP/IP) before
the name of the server. For tcp/ip,
you can also try adding the port
number (,1433) after the name of the
server. If this is not the default
instance, you must add the name of the
instance after the name of the server;
for example:
> sqlcmd -S
> tcp:NameOfTheServer\sqlexpress,1433
EDIT: removed source link, as it is now a dead link
Bofe's answer worked, so that gave an indication that something was askew with the ports.
It turns out that in the TCP/IP settings for the named instances, I had listen All set on the protocol, and then had a static port set for IPAll, but dynamic port set for IP1. I had assumed that since IP1 was disabled, I didn't need to worry about it, but apparently if you have Listen All set, then the enabled property for IP1 is ignored. So, having only one ip address on the server, and configuring IP1 dynamic ports, and IPAll static ports caused some sort of weird conflict.
To fix the problem, I just set IP1 to use the same static port as IPAll, enabled IP1, rebooted the server, and things worked like they were supposed to, without having to explicitly set the port in the connection string.
Try using different TCP/IP ports for each instance on the server. You will need to go into the SQL Server Configuration Manager to change these settings. Under TCP/IP you can change the port numbers and then use these in your connection string or in SQL Management Studio when connecting.
Out of curiosity, why do you have for instances o the server? Can you use one instance and have multiple databases instead? If you are using other instances for development or testing you might want to consider moving those to another box.
Try enabling TCP/IP communication to the SQL server instances. If you are eventually going to be traversing a firewall, you'll probably want to use TCP/IP instead of named pipes anyway.
Related
I'm running SQL Server 2012 on a Microsoft Windows Server 2012 R2. I am running a named instance called PP. The server authentication is set to "SQL Server and Windows Authentication mode".
When I am logged into the server via Remote Desktop I can log in to the named instance via SSMS just fine using a using a SQL Server username and password. When I try to log into the named instance remotely using the same username and password I get an error as described in this screenshot (my reputation isn't high enough to paste the screenshot directly in my post, please follow the link):
Here are the things I have checked so far:
I can ping the IP Address of the remote server from my local computer and get successful responses.
I have configured the instance of SQL Server to accept remote connections as described in this article.
In SQL Server Configuration Manager on the remote server under the protocols for my named instance I have enabled "Shared Memory", "Named Pipes" and "TCP/IP".
Under "TCP/IP" properties on the remote server in SQL Server Configuration Manager in the "IP Addresses" tab under the "IP2" section I have set the "TCP Dynamic Ports" value to blank. I have tried setting the "TCP Port" value to 1433 and then to 1434 (the difference between a regular instance and a named instance) and going through the rest of the steps below as shown in the screenshot here (these are the values specified in the article I linked to above)
Windows firewall is not running on the remote server, and from what I can see there is not another firewall running on the remote server either.
The SQL Server Browser service on the remote server has been stopped and restarted.
After I have made all of these changes and verified all of these settings the SQL Server service for the named instance on the remote server has been stopped and restarted.
After all of this I am still getting my original error when I try to connect to the named instance of SQL Server on my remote server from my local computer via SSMS. I've been searching high and low and cannot find any additional troubleshooting steps to diagnose this problem. Will someone please point me in the direction of the next steps I should take to fix this? Thanks in advance.
I logged off and then came back the next day to implement the suggestions in #Andrey Nikolov 's answer and for some reason I am able to connect remotely to the named instance now. The settings that ended up working for the "IP2" section of the "TCP/IP" configuration for the named instance are the "TCP Dynamic Ports" value is set to blank and the "TCP port" is set to 1433. I didn't make any other changes. The rest of the configuration is as I noted in my OP. I have sysadmin access to this server but I'm not the actual administrator so I guess it's possible that the actual administrator might have changed something else between when I logged off and then logged back on but I don't know what that might be. Thanks to #Andrey Nikolov for your input.
EDIT:
This issue came back in full force a few days later for no reason that I could determine. After a long search I found a very informative MS Doc that goes through the whole troubleshooting process for this in depth, hope this helps someone else confronted with this. Here's the link:
https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/troubleshoot-connecting-to-the-sql-server-database-engine?view=sql-server-2017
It says it's for SQL Server 2017 but I was able to follow it to fix my SQL Server 2012 issue. For my situation it turns out that because I had 2 separate instances of MS SQL on my server the initial instance was using all of the default settings as described elsewhere and my instance I was trying to connect to was using a completely different port. Using this Doc I was able to find out what port my instance is using and specify that in the "Server name" box of SSMS when I tried to connect. Now it works like a charm.
I think your named instance TCP/IP isn't configured properly. In case you connect locally it does not connect using TCP/IP, but using shared memory. You set your instance to listen on port 1434, but this port is used by SQL Browser service and most likely the SQL Server engine service can't open the port (you can confirm that by finding the error in the logs). To make it work you should set IP2 -> TCP Dynamic Ports to be 0 and clear IP2 -> TCP Port. Configured like this, your named instance will use dynamic ports. If you want to configure it to use specific port, replace 1434 in IP2 -> TCP Port with available port number.
I am having an issue connecting to a SQL server instance with management studio over VPN. I can connect to the default instance (i.e. SERVERNAME) over the VPN connection but I cannot connect to another instance on the same server (i.e SERVERNAME\INSTANCE) over the same VPN connection. All of the settings are the same in SQL Configuration manager.
Additionally, I can connect to the named instance just fine from any box "inside" the network. The error I am receiving is a general, "A network-related or instance-specific error occurred... Error 26."
Thanks
EDIT: I should also point out that I can use IPADDRESS to connect, but IPADDRESS\INSTANCE does not work.
To (partially) resolve the situation you need to choose from one of these workarounds when connecting over VPN:
Enable and use SQL Server Authentication instead of Windows Authentication and a static port for the SQL Server instance (always specifying the port value in the connection string);
Use a static port for the SQL Server instance (always specifying the port value in the connection string), enable that TCP port in your server firewalls, and specify the public server name or its external IP address (provided that it is exposed outside the local network);
Enable trust between your source and destination domains (not applicable for connections “on the fly”).
Personally I decided to use the first workaround as it was the easier to implement and the most secure however If the problem persists, verify the server doesn't have an IPSEC policy that restricts access to the SQL Server port via IP address. That also could result in you being blocked.
I have two instances of SQL Server on my local machine. They both listen to separate ports. The first instance that I installed runs on the default port: 1433. I have set the other to listen to port 1434.
My application is using some old shared code that we have here to generate the connection string. So until now I didn't really know what was happening there. Due to a new requirement I found myself needing to examine the connection strings that I'm using to connect to the SQL Server.
What I found that was that for the connection string be built to connect to each of the SQL instances did not include Network Library, nor did they include the port number as part of the Data Source. The Data Source was just set to <Server Name>/<Instance Name>. I did find in the MS documentation that if the Network Library is not included then it is treated as (local), but it doesn't really explain how (local) is treated.
So my question is why is a connection string in this format able to connect to the SQL Server instance that runs on the non-default port? will this only work if the instances are on the local machine, or local network? Can I put <ip>/<sql instance> without the port if the server is remote?
I just need some clarity on how this works, and when is the port number needed and when it is optional as I'm trying to make my connection UI as simple as possible for our users.
There is such a thing called "SQL Server Browser Service":
http://technet.microsoft.com/en-us/library/ms181087(v=sql.105).aspx
It is intended to provide clients with information about sql server instances, ports. It actually listens on UDP port 1434.
With this service turned off you will still be able to connect to the instance, but you need to specify TCP/IP port.
I have two instances of SQL Server on my local machine. They both listen to separate ports. The first instance that I installed runs on the default port: 1433. I have set the other to listen to port 1434.
Just out of curiousity, why don't you just have them setup as named instances both running on the default of 1433 ?
As for why it works, if you search for SQL Configuration in your start menu, you'll find a screen similar to this.
Sql Server supports a number of different ways of connecting. TCP/IP is one way (ie IP addresses and ports) but it also supports a Shared Memory connection if you're on the local machine. that is, if you SQL Server executable, and management studio/client are also on the same machine.
At a guess I'd say it defaults to shared memory when you specify local and therefore you don't need to specify the port.
You could test this out by temporarily disabling shared memory in the above config, and see if your (local)\InstanceName stops working.
Check out this pic of my SQL 2008 Management Configuration screen for TCP:
I need to know what port I am running on. Based on this previous post, I don't believe that it is 1433, which I guess is the default.
When I check my port number in SQL Config Mgr., it is blank. Does this suggest a default port? Note that I have multiple SQL Server instances on the db server. One 2000 instance and two 2008 instances. I want to know the port of the 2008b instance.
The first display is for TCP. I'm not sure what VIA is, but check it out:
Can you help?
Update
I restarted my sql2008b instance and checked the log to look for a msg that indicated the port that it was using. It showed this:
2010-05-22 20:06:29.27 Server A self-generated certificate was successfully loaded for encryption.
2010-05-22 20:06:29.27 Server Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\SQL2008B ].
2010-05-22 20:06:29.27 Server Server local connection provider is ready to accept connection on [ \\.\pipe\MSSQL$SQL2008B\sql\query ].
2010-05-22 20:06:29.32 Server Server is listening on [ 127.0.0.1 <ipv4> 5786].
2010-05-22 20:06:29.32 Server Dedicated admin connection support was established for listening locally on port 5786.
Yet, when I tried to log on using the following as the server name:
(local)\sql2008b,5786
I still was unable to connect, while logged onto the remote box (hence using "local".)
A suggstion was made below to set the port myself. This occurred to me to try but there are a couple of things that are botehring me:
1) Why can I connect to my SQL 2000 instance without monkeying with anything to get it to work (but not my 2008 instance)?
2) The IP addresses shown in TCP1 and 2 don't appear correct. The one I blacnked out, presumably theIP address of my router and the one needed to make my server visible on the Internet, was not correct. Also , the local 192.168.1.100 was not correct. The db server server's IP adress end in a different number. perhaps I sh
TCP/IP is disabled in your screenshot so it isn't listening on any port. On start up when enabled it will write an entry to the SQL Server logs telling you what port it is listening to. (Accessible through Management Studio tree view Management -> Sql Server Logs nodes)
You might find this link useful How to configure an instance of SQL Server to listen on a specific TCP port or dynamic port
Also do you have the SQL Server Browser service running on that machine (it might help you connecting to the right instance)?
If TCP/IP is disabled, the service can still listen via Named Pipes (for network connections) or Shared Memory (for local connections), so it will work with TCP/IP disabled if you choose to got that route.
On startup, there will be an event log entry to tell you what connection methods it's listening for, or you can do a "NETSTAT -A" from the command line to see which ports the server is listening on in general.
I am unable to connect to my local instance of SQL Server 2008 Express using SQL Server Management Studio.
I believe the problem is related to a change I made to the connection protocols. Before the error occurred, I had Shared Memory enabled and Named Pipes and TCP/IP disabled. I then enabled both Named Pipes and TCP/IP, and this is when I started experiencing the problem.
When I try to connect to the server with SSMS (with either my SQL server sysadmin login or with windows authentication), I get the following error message:
A connection was successfully established with the server, but then an error occurred during the login process. (provider: Named Pipes Provider, error: 0 - No process is on the other end of the pipe.) (Microsoft SQL Server, Error: 233)
Why is it returning a Named Pipes error? Why would it not just use Shared Memory, as this has a higher priority order in the list of connection protocols? It seems like it is not listening on Shared Memory for some reason?
When I set Named Pipes to enabled and try to connect, I get the same error message.
My windows account is does not have administrator priviliges on my computer - perhaps this is making a difference in some way (as some of the discussions in this post about an "SuperSocketNetLib\Lpc" registry key seems to suggest).
Had the same problem. Here is what solved it for me:
Open SQL Management Studio
Connected through the admin account I used to setup the instance
Selected the server from Object Explorer
Right mouse click properties
Server properties opens
Go to Security
Changed it from Windows Authentication mode to SQL Server and Windows Authentication Mode
I didi everything google teaches and can't connect with TCP/IP successfully. Then I do these steps to make it work in my home computer:
step 1. Enable TCP/IP in SQL Server Network Configuration for your DB instance.
step 2. Choose properties of TCP/IP and click IP Addresses tab.
step 3. Inactive all IP address except 127.0.0.1.
step 4. Set TCP Port to 1433 in 127.0.0.1 and IPALL.
step 5. Restart sql server service.
step 6. Connect it with TCP/IP using '127.0.0.1\SQLEXPRESS,1433' in Toad for SQL Server freeware, it works!
step 7. Connect it with same server string in php, it works!
step 8. If you need read Chinese string into php program as I am, download MS SQL Server driver for PHP(Believe me, don't even try php_mssql stuff, it'll drive you crazy with Chinese data). For PHP 5.2x, use ts_VC6 version. For 5.3X, use ts_VC9 version (especially when in Win7).
step 9. Edit php.ini (For Appserv, it's under C:\Windows7; for WAMPserver 2.2, it's under c:\wamp\bin\php\php5.3.8), find extension=... line groups. Add 'extension = specific sql erver driver dll filename you are to use.
step 10. Unzip the file downloaded in step 8 and copy the specific dll (or copy all) to php extension directory (you can find it in php.ini's extension_dir=... line). For Appserv, you better copy it to c:\windows\system32, too(Don't ask me why?).
step 11. restart apache service of Appserv or restart Wampserver.
Now you can use TCP/IP to connect with SQL Server 2008 and you can read utf-8 string (in my case) into php program correctly.
Hope this helps those who are deperately looking for this solution, as i am.
Since now you cannot connect to SQL Server to disable named pipes, you have to force a TCPIP connection.
Here's how:
click on START / RUN then run the cliconfg.exe utility. In this, create an alias for your server (you can use the same name) and put the default for TCPIP
That should force TCPIP over Named Pipes and maybe get you connected.
Try connecting to the alias name that you used in CliConfg and it will now connect using TCPIP.
I had this exact same problem. I'd try connecting as ASHWHVM004\SQLEXPRESS and I'd get a connection failed message. If I explicitly requested Shared Memory, it'd work fine. Shared Memory, Named Pipes, and TCP/IP were all enabled.
I seemingly "fixed" it by doing the following:
I opened up Sql Server Configuration Manager and drilled down to SQL Server Network Configuration > Protocols for SQLEXPRESS.
I disabled everything except Shared Memory.
I restarted the SQLEXPRESS service instance and tried connecting as before. It worked fine.
I enabled TCP/IP and Named Pipes and restarted the SQLEXPRESS service instance and tried connecting as before. It worked fine.
Either I did something else during this process to fix it that I don't recall, or the act of disabling and re-enabling caused some twiddly bit to get flipped back the right way.
Good luck!