I try to login to SQL SERVER 2008 from another computer (IP is 10.225.3.137).
The database name is MSSQLSERVER2008, TCP protocol is port 49172.
The account is SQL Server Authentication.
I read from an article here to login to the database engine from another computer. Server name is "tcp:10.225.3.137,49172" and it works.
Here is the sceenshot:
I try to login from another computer to this database with server name is "10.225.3.137\MSSQLSERVER2008" but it doesn't work. Here is the screenshot. However, with the same server name on computer that installed SQL SERVER 2008, it works.
Anyone here can explain for me please? And how to login to that database from another computer with server name is "10.225.3.137\MSSQLSERVER2008"?
Be sure that SQL server is listening on default port and is set up for remote access and firewall is set up for default port 1433 and TCP/IP connections are enabled.
Looking at both images, it looks like it is not listening on port 1433 but 49172. Then change your connection to read:
10.225.3.137,49172\MSSQLSERVER2008
(you might prefix with tcp:)
Note: I have an old series of videos on youtube if you kike to watch, that shows setting up SQL server express locally and then connecting from remote using a custom port (search for "AccuSQL installation" on youtube and you would see 4 parts of videos - part 3 or 4 was about remote connection).
And BTW that is called an "INSTANCE" not database.
Related
I have a client for which I am setting up a new SQL Server Express and (on a different computer) connecting their Access front end to that SQL Server. I created an account on SQL Server, changed authentication to SQL Server. I am able to log on to that account with no issues locally (through SQL Server Management Studio) on the server itself, but when I go back to the client machine and try to create either an ODBC connection or connect directly in Linked Table manager, I get the error below. Looking at the error log in SQL Server I can see no failed logins. In Access and/or ODBC I use Servername\SQLEXPRESS, choose SQL authentication and type in the username/password that I created. But it's still being stubborn.
I'm kind of at my wits end with this one. I checked to make sure that login is enabled, that the created database is mapped to this user, but I'm out of answers. Anyone have any ideas? I'm sure it's something really stupid that I'm overlooking, I've used SQL Server for a long time but I'm not an experienced DB Administrator I'm sure it's something really simple I'm overlooking, but I've done this hundreds of times before. And Windows Authentication won't work because it's on a different computer.
To connect to a named instance on SQL Server Express with Servername\SQLEXPRESS, you need:
SQL Server Browser service running,
and its UDP port 1434 open in the firewall.
https://learn.microsoft.com/en-us/sql/sql-server/install/configure-the-windows-firewall-to-allow-sql-server-access
SQL Server Browser service
UDP port 1434
The SQL Server Browser service listens for incoming connections to a named instance and provides the client the TCP port number that corresponds to that named instance.
The fixed TCP port for your instance open in the firewall.
You set this in SQL Server Configuration Manager
https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-a-server-to-listen-on-a-specific-tcp-port
This looks more like a network setting rather than server issue.
Check if all necessary permissions, configuration and settings on your machine running the server are OK to accept external connections.
Usually its the server that is rejecting the connection for security reasons.
i moved my website on a server, it have installed web application and SQL server instance (this site is only for private network), if i try to access sql instance from SSMS it connect without problem, but when i try to access data from my website or SSMS installed on another pc connected to the same network it's says me that instance name is not correct or firewall block sql server ports. Sql connection string is correct, both SQL Server and SQL Browser services are active, named pipes and TCP are enabled, and i've added rules to firewall to allow connection from port 1433 and 1434(this one is for UDP) but i've the same problem, any help?
I created an Azure SQL Server. I have set the firewall, added my IP address to the rules. I tried to log in using SQL Server Managment Studio but got the network error every time. I am using the Server Admin Login and password created while creating the SQL server. Are there any more steps required to log into the SQL Server?
Note: I also enabled port 1433 for inbound connections on my PC.
According to the error message, we should check the server name of the database.
We can select the database here, and SQL Server Managment Studio will type the server name automatically:
Another way, we can find the information via azure portal, then type the server name manually:
It seems you are using named pipes to connect to SQL database. What happens if you specify TCP/IP protocol in advanced properties tab?
Thanks Everyone for your inputs. The only issue was, the firewall was blocking the port 1433. After opening it, I could connect to the SQL Server hosted in Azure. The link below mentions the requirement to open the said port. https://learn.microsoft.com/en-us/azure/sql-database/sql-database-develop-direct-route-ports-adonet-v12
Initial Attempt
I have an Azure VM with Windows Server 2012, on which I just installed SQL Server 2012 Express Database Engine component. Then, I followed the instructions here to connect remotely with SQL Server Management Studio.
Create a TCP endpoint for the virtual machine
Open TCP ports in the Windows firewall
Configure SQL Server to listen on the TCP protocol
Configure SQL Server for mixed mode authentication
Create SQL Server authentication logins
Determine the DNS name of the virtual machine
Connect to the Database Engine from another computer
After step seven I received the following 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)
(Microsoft SQL Server, Error: 53)
What else do I need to configure before connecting remotely?
Troubleshooting
I have been following the troubleshooting instructions here. Each blockquote below is a step described that that link.
Confirm the instance of the SQL Server Database Engine is installed
and running.
Done. We installed SQL Server Express, and it is running as a named instance called SQLEXPRESS.
If you are attempting to connect to a named instance, make sure the
SQL Server Browser service is running.
Done. We followed the steps here to turn on the SQL Server Browser service.
Get the IP Address of the computer.
Done. We will use these later for testing connectivity and maybe for setting up a static port for SQLEXPRESS.
10.241.62.155
fe80::45c:8c29:e19f:f78b%15
Get the TCP port number used by SQL Server.
Done. The SQL Server Management Studio server logs showed that the server was listening on port 49169.
Enable Protocols
Done. We had already enabled TCP/IP in the configuration manager, but we restarted the SQL Server Service just in case.
Testing TCP/IP Connectivity
Done. We used tcping.exe to test connectivity (cmd ping doesn't work quickly with Azure.) We were able to connect to port 80.
tcping.exe buddha.cloudapp.net > successful
tcping.exe buddha.cloudapp.net 80 > successful
Testing a Local Connection
Done. We used sqlcmd.exe from the command prompt and were able to connect locally via TCP with a username and password.
sqlcmd -S Buddha\SQLEXPRESS (success via shared memory protocol)
sqlcmd -S tcp:Buddha\SQLEXPRESS (success via TCP)
sqlcmd -S tcp:Buddha\SQLEXPRESS -U sa -P (success via TCP with username)
sqlcmd -S tcp:10.241.62.155\SQLEXPRESS -U sa -P (success with internal IP)
Opening a Port in the Firewall
We opened the port on which we SQLEXPRESS listens. The server logs (above) showed that SQLEXPRESS was listening on port 49169, but this is just one of many dynamic ports, and we wanted to set up the static port 1435.
Use WF.msc to create an inbound TCP rule for port 1435.
Use Azure Management Portal to create a TCP endpoint for port 1435.
The troubleshooting instructions also say:
If you are connecting to a named instance or a port other than TCP
port 1433, you must also open the UDP port 1434 for the SQL Server
Browser service.
Since we are connecting SQLEXPRESS (a named instance), we needed to open port 1434 for UDP.
Use WF.msc to create an inbound UCP rule for port 1434.
Use Azure Management Portal to create a UDP endpoint for port 1434
Further research about connecting to named instances revealed dynamic port issues. The reason why we are using port 1435 (static) instead of port 49169 (one of many effective options.)
Instances of SQL Server Express, SQL Server Compact, and named
instances of the Database Engine use dynamic ports. To configure these
instances to use a specific port, see Configure a Server to Listen on
a Specific TCP Port (SQL Server Configuration Manager). and
here.
Done. We went to SQL Configuration Manager > SQL Server Network Configuration > Protocols for SQLEXPRESS > TCP/IP, we did the following.
Protocol Tab > Listen All > NO.
IP Addresses Tab > for each listed address
Enabled > Yes
TCP Dynamic Ports > Blank (delete the zero)
TCP Port > 1435 (or your choice)
After restarting the SQLEXPRESS service, we again looked in the SQL Server Management Studio logs, and found that the Server is Listening on port 1435!!! Hooray!
Testing the Connection
Done. We opened SQL Server Management Studio on our local (non-Azure) computer and connected.
buddha.cloudapp.net,1435 OR buddha.cloudapp.net\SQLEXPRESS
sa
password
Success.
Here are the three web pages on which we found the answer. The most difficult part was setting up static ports for SQLEXPRESS.
Provisioning a SQL Server Virtual Machine on Windows Azure. These initial instructions provided 25% of the answer.
How to Troubleshoot Connecting to the SQL Server Database Engine. Reading this carefully provided another 50% of the answer.
How to configure SQL server to listen on different ports on different IP addresses?. This enabled setting up static ports for named instances (eg SQLEXPRESS.) It took us the final 25% of the way to the answer.
The fact that you're getting an error from the Names Pipes Provider tells us that you're not using the TCP/IP protocol when you're trying to establish the connection. Try adding the "tcp" prefix and specifying the port number:
tcp:name.cloudapp.net,1433
I too struggled with something similar. My guess is your actual problem is connecting to a SQL Express instance running on a different machine. The steps to do this can be summarized as follows:
Ensure SQL Express is configured for SQL Authentication as well as Windows Authentication (the default). You do this via SQL Server Management Studio (SSMS) Server Properties/Security
In SSMS create a new login called "sqlUser", say, with a suitable password, "sql", say. Ensure this new login is set for SQL Authentication, not Windows Authentication. SSMS Server Security/Logins/Properties/General. Also ensure "Enforce password policy" is unchecked
Under Properties/Server Roles ensure this new user has the "sysadmin" role
In SQL Server Configuration Manager SSCM (search for SQLServerManagerxx.msc file in Windows\SysWOW64 if you can't find SSCM) under SQL Server Network Configuration/Protocols for SQLExpress make sure TCP/IP is enabled. You can disable Named Pipes if you want
Right-click protocol TCP/IP and on the IPAddresses tab, ensure every one of the IP addresses is set to Enabled Yes, and TCP Port 1433 (this is the default port for SQL Server)
In Windows Firewall (WF.msc) create two new Inbound Rules - one for SQL Server and another for SQL Browser Service. For SQL Server you need to open TCP Port 1433 (if you are using the default port for SQL Server) and very importantly for the SQL Browser Service you need to open UDP Port 1434. Name these two rules suitably in your firewall
Stop and restart the SQL Server Service using either SSCM or the Services.msc snap-in
In the Services.msc snap-in make sure SQL Browser Service Startup Type is Automatic and then start this service
At this point you should be able to connect remotely, using SQL Authentication, user "sqlUser" password "sql" to the SQL Express instance configured as above. A final tip and easy way to check this out is to create an empty text file with the .UDL extension, say "Test.UDL" on your desktop. Double-clicking to edit this file invokes the Microsoft Data Link Properties dialog with which you can quickly test your remote SQL connection
I need help connecting from a blank access 2010 database to my remote SQL Server 2005 database. This is because I'm going to write all my client apps in Access, and store everything on the server with SQL Server. I'm using the wizard, and trying to make a new DSN. What do I put for:
Which SQL Server do you want to connect to?
Server:
The server is windows server 2008, and it is remote. I've been connecting to it with a .RDP file, but I'm not sure how to set up the link.
Please ask me to clarify anything that doesn't make sense.
Thanks.
Enter the IP address or the Windows Host Name for the server that has SQL Server on it.
You'll need to make sure that your server has port 1433 open in it's internal software firewall. If you're going through any kind of router that router will also need to have port forwarding and possibly the firewall opened up for port 1433.
Also, you'll need to make sure that your SQL Server instance is setup to listen on TCP/IP with port 1433 (unless you choose a different port).
You might be best off trying to connect to it from SQL Server Management Studio first. Once you have that working you should have an easier time setting up your DSN.
For troubleshooting, see this:
http://blogs.msdn.com/b/sql_protocols/archive/2005/10/22/sql-server-2005-connectivity-issue-troubleshoot-part-i.aspx
http://blogs.msdn.com/b/sql_protocols/archive/2006/09/30/sql-server-2005-remote-connectivity-issue-troubleshooting.aspx