I have a SQL Server 2000 install on a server that I am having weird connection issues with.
Using SSMS I can't connect to it using an Alias I have setup on Configuration Manager. The Alias is set to use TCPIP which is the first protocol in the order below shared memory. If I use the exact same server name I put into the Alias then I can connect just fine.
I see the exact same behavior in my ASP.NET application, using the alias I get a connection failure, using the name it connects just fine. The ASP.NET connection string is not specifying a protocol.
Using the server name will use the default connection protocol for the client.
This may be named pipes or tcp/ip (MDAC version, upgrade vs install etc).
The Alias is set to use TCPIP which is
the first protocol in the order below
shared memory
I assume that if the client alias is set to use tcp, then the server is only configured to listen on named pipes so it only works with server name. The client will eventually find named pipes in it's list of protocols to use.
To test, replace servername with np:servername and tcp:servername to change the protocol without using the alias.
Or check what the server is listening on and fix that...
The other option is a non-standard TCP port (server, not 1433) or firewall preventing access to port 1433/1434.
SQL 2000 Books
Does the alias specify a protocol? Is that protocol accepted by the server? Is that the protocol being used when you are connecting by name? (i.e. what is the order of client protocols)
Related
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.
I have two development teams, that come from different groups.
Group A develops against a local default instance of Sql Server 2008 R2;
Group B develops against a local named instance of Sql Server 2008 R2.
Is there a way to setup an alias such that both groups are coding against the same name? As it stands right now we have a war of Connection Strings as group B changes (local) to ./DEV and group A changes it back again?
In SQL Server Configuration Manager, under the SQL server native client configuration section there is a subsection called "aliases" you can add an alias into here that points to your named instance. You just use the alias as if it is the default instance on a server with the name of the alias. We use this exact model and have only one connection string that points to a standard alias. Each developer has the same alias name pointing to their own instance.
Aliasing to a Local SqlExpress Instance
To expand on Ben's answer, I had the specific requirement to alias a connection string pointed at a specific Server Instance, and instead re-route this to our local developer Sql Express instances, i.e. to alias from:
SomeServer\SomeInstance
to
.\SQLExpress
This proved somewhat tricky until I found this link here. My Sql Express instance was running on the standard port 1433 (i.e. adapt to suite)
Enable TCP/IP for SqlExpress
Since aliasing is done via TCP/IP ports, TCP/IP protocol must be enabled. (Opening SqlExpress for remote access isn't necessary if you are working locally).
Using Under Sql Server -> Configuration Tools -> Sql Server Configuration Manager:
At the same time, set the Listen All property to Yes.
Enable LocalHost IP's
Ensure that both IPv4 (127.0.0.1) and IPv6 (::1) localhosts are active and enabled.
On each IP's, Leave the Dynamic Port at zero (as the name suggests, the port will be allocated dynamically). The IPAll Dynamic and TCP Ports are then used globally.
You'll need to restart the MSSQLServer / SqlExpress service to effect the change.
Creating Aliases (32 and 64 bit)
Under the Sql Native Client xx Configurations, this requires simply adding the alias "From" Server\Instance as the Alias Name and the actual server + instance as the Server (i.e. my local SqlExpress instance). I was able to connect via both port 1433, or the dynamic port on IpAll (9876), although saw no reason to use the latter. The aliases must be done for both 32 and 64 bit client configurations.
You should now be able to connect using the aliased SomeServer\SomeInstance via SSMS.
Other Notes
Since I was aliasing to a local instance, I did NOT have to add an alias for the from host, SomeServer to a DNS or LocalHosts. This will likely be required however if you are aliasing to a remote server (plus I guess some other security headaches)
I did not need to have the Sql Browser service running.
So it would seem that the Sql Client configuration takes care of the substitution prior to any network or security steps.
Personally, I'd make them all use the same box.
That said, you can set local aliases per developer's box using SQL Server Client tools.
Anything IP address or server name based (such as hosts file or DNS) will fail because instance names (and ports used) are different
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.
I am trying to connect to a Microsoft SQL 2005 server which is not on port 1433. How do I indicate a different port number when connecting to the server using SQL Management Studio?
127.0.0.1,6283
Add a comma between the ip and port
If you're connecting to a named instance and UDP is not available when connecting to it, then you may need to specify the protocol as well.
Example: tcp:192.168.1.21\SQL2K5,1443
Another way is to setup an alias in Config Manager. Then simply type that alias name when you want to connect. This makes it much easier and is more prefereable when you have to manage several servers/instances and/or servers on multiple ports and/or multiple protocols. Give them friendly names and it becomes much easier to remember them.
You'll need the SQL Server Configuration Manager. Go to Sql Native Client Configuration, Select Client Protocols, Right Click on TCP/IP and set your default port there.
Using the client manager affects all connections or sets a client machine specific alias.
Use the comma as above: this can be used in an app.config too
It's probably needed if you have firewalls between you and the server too...
On Windows plattform with server execute command:
netstat -a -b
look for sql server processes and find port f.e 49198
Or easier. Connect with dbvisualizer, run netstat -a -b find dbvis.exe process and get port.