Currently to connect to my SQLEXPRESS server I need to do the following:
152.152.152.152\SQLEXPRESS
Can I do anything so it removes the need to specify the "\SQLEXPRESS" part and just connect with IP address?
Thanks Paul
You need to enable TCP protocol on the instance and assign ports it listens on. Then you will be able to just connect to it using the IP address and port number.
You can use SQL Server Configuration Manager to do it, just see [1].
After that you just connect using TCP/IP, like in this example tcp:127.0.0.1,1433.
Note that if the port is 1433, like in this example, you can just omit it, like this tcp:127.0.0.1.
If you want to connect from remote machines you need to open the port on the firewall as well.
[1] http://msdn.microsoft.com/en-us/library/ms177440.aspx
Related
I have to connect to a fresh SQL Server Express 2017 on a machine not part of my domain. I have configured
Mixed Mode Installation with sa with password
SSMS -> Server -> Properties -> Connections -> Allow remote connections
SQL Configuration Manager -> Instance "EXPRESS2017" -> TCP/IP: Enable and Active and Port 1438
Restarted the "SQL Server (EXPRESS2017)" service.
I now tried to access from a remote computer, and got a timeout. I then tried to connect from the local SSMS, which works without special settings, but when under options, forced "Protocol: TCP/IP" is set, with the same credentials as before, I also got a timeout.
So am I right that I can rule out the firewall or problems finding the instance, and everything points towards a configuration issue in TCP/IP protocol, or did I overlook some setting?
EDIT: I have disabled Windows firewall, and no other firewall is installed on the computer. I have restarted the computer. I also found this article about PortQry and had a check - locally:
C:\Users\Administrator\Downloads>PortQry.exe -n 172.17.41.124 -p UDP -e 1434
Querying target system called:
172.17.41.124
Attempting to resolve IP address to a name...
IP address resolved to WIN-AECL8CJVS7E.test.local
querying...
UDP port 1434 (ms-sql-m service): NOT LISTENING
EDIT: I have run NETSTAT and it seems no port in the 14xx range is open at all, although the SQL Server Browser service is running. I must be missing something there...
You did not show your connection string, but I suppose you use your instance name here.
In order to connect to SQL Server the network library has to know 2 things: IP address and a port. Your instance is named and uses non-default port 1438.
So your connection string should use 172.17.41.124,1438 as server name, or, alternatively, you can use instance name like this: 172.17.41.124\EXPRESS2017 but SQL Server Browser should run.
i have an application that needs database(sql server 2008 r2) through public ip, so that the user can use his application anywhere.
i configured the router for port forwading,
i add the port and sql-browser in the firewall.
and when i try datasource = [publicIp]\SQLEXPRESS,1433 i can only access the server when im in the network..
but cannot access the server when im not in the network..and also cant ping the public ip..
i opened port 1433 already.
what seems to be the problem?
Port 1433 isn't enough. When you're running a different than default instance, it will run on a different port. Usually, SQL browser service would help you find it, but you have to forward all the relevant ports as well, which is quite unwieldy. Instead, try setting the correct port manually in SQL server configuration, and connect with the explicit 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.
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'm attempting to access a SQL Server which is exposed through an IP NAT mapping. All the ports are open. I don't know the details of the NAT, if it's relevant, since that's somewhere else in the company hidden in a pile of red tape.
Here's what I figured out. When you attempt to access a named instance of SQL Server, the client asks what port the named instance is running on. If I RDP into the SQL Server I can use netstat to find out the port of that instance and can successfully connect through the firewall. However, connecting via the instance name doesn't work. My guess is that the server is responding at some point with it's internal IP address and the client is using that.
Does anyone know if this is true and if there's a way around it?
The instance listening port protocol discovery is subject to the SQL Server Browser Service. This uses UDP on 1434. With a NAT forwarding of UDP 1434 your client should be able to interact with the SQL Server Browser Service (if the SQL Server Browser's UDP response packet can reach back the client, a big if), but even a successful interaction will put your client in a tight spot: now that it knows the SQL Server dynamic listen port, how does it reach it? The NAT would have to dynamically forward the port picked by SQL Server, or it would have to forward all ports.
What I recommend is to have your SQL Server listen on a per-configured, statically assigned, port. See How to configure an instance of SQL Server to listen on a specific TCP port or dynamic port. Have your NAT forward that port. Then in your client use this port explicitly in the connection string. Do not use 1433, the standard port, since I assume that ahead of the NAT is the public internet and 1433 is subject to constant and frequent scans from all sort of bots and vile clusters.
Configure the named instance to run on a static port using SQL Server Configuration Manager. In configuration manager, SQL Server Network Configuration -> Protocols for <named instance> -> TCP/IP -> Properties.
Then supply the hostname and port for the named instance in the connection string. The hostname and port number are specified in the following format (assuming hostname is Test and listen port is 1492):
... Server='Test,1492'; ...
I need to access an SQL Server that is on a machine behind a firewall and you access this machine using an ip address like 95.95.95.33:6930 (not the real ip address) ... But, you get my point that by accessing 95.95.95.33 on port 6930, the firewall routes the requests to that particular machine ...
My question is ... How do you construct a connection string to access the machine at address 95.95.95.33:6930 and then further access the SQL Server on port 1433 or maybe a different port like 8484 ???
Thanks
Mike
well, you build the connection string like this
"Server=95.95.95.33,6930;database=mydb;..."
the firewall/nat will have to route that to the correct machine/port of the SQL server for you.
All you should worry about is the public address and port number of the SQL server. It makes no difference to you to which internal machine and port number the connection is forwarded to.
You then build a connection string as described on connectionstrings.com:
Data Source=95.95.95.33,6930;Network Library=DBMSSOCN;Initial Catalog=myDataBase;User ID=myUsername;Password=myPassword;
DBMSSOCN=TCP/IP. This is how to use
TCP/IP instead of Named Pipes. At the
end of the Data Source is the port to
use. 1433 is the default port for SQL
Server.