I have a SQL Server running on Microsoft Azure. I want to connect it to My Project in Visual Studio 2015 Community. I have added my IP address in firewall on server. I have also made my port 1433 open for sql. But when I try to connect to database this error shows up. Error Message in SQL Server
It appears that this is a two step process and you either missed the VM configuration or the Azure configuration. Based on what you said I believe it is the Azure configuration that may have been missed. This blog post appears to highlight the necessary things that need to be done to connect.
https://blogs.msdn.microsoft.com/ggaurav/2014/01/08/connect-to-sql-database-on-azure-iaas-from-ssms/
Below is an excerpt:
The two settings which you have to make sure you are checking are :
Endpoint is configured for the port on which SQL server is listening ( generally 1433) on the VM machine.
Ports are opened on the VM machine. Even though as per the documentation Cloud adaptor takes care of opening the firewall ports,
it doesn’t work for the normal connections which you are trying to
make. Just type in ” wf.msc” and create a rule for both outgoing and
incoming for TCP port 1433.
As soon as you are done with these two, you would be able to connect
to the SQL server on the VM machine.
According to your description, I guess your SQL database is a Azure service, not install SQL on Azure VM.
If I understand it correctly, we should check SQL database firewall settings and confirm the name of your database.
The error code means, this error could occur because either the
firewall on the server has refused the connection or the server is not
configured to accept remote connections.
We can via Azure Portal to check the firewall settings:
Make sure the Allow access to Azure Services is ON,
And make sure your client IP address have added to the Client IP address list.
Also we should confirm the name of your database, make sure we are connect to the right SQL database.
I have also made my port 1433 open for sql. But when I try to connect to database this error shows up.
You also need to enable 1433 port in Network Security Group which related to your VM. Steps below are for your reference.
Find the Network Security Group name which related to your VM in Netowrk interfaces panel.
Open this NSG, click [Add] button in the Inbound security rules panel
Add a rule as following.
After that, we could access the database hosted in VM using following server name format.
Server name format.
[IP address/dns name],1433
For example,
13.81.50.123,1433
how to connect two laptops to share a database using windows form application? i mean i've installed mssql server 2008 in my laptop, i need to make windows form application so my friend can modify the database from his laptop, it's not in LAN , we have to use Internet as medium to connect, it'd be helpful if anyone can show me some directions like how connection strings should be. thanks :)
You should consider looking into this. If you search for Error 40 or Error 26 SQL Server. You will get lot of links for connecting SQL Server remotely both on LAN and WAN.
Take a look at this link as well. Screenshots are added here
There are multiple steps involved
Enable default login (sa) - not a good practice
Enable remote connection on sql server
Enable SqlBrowser service - either through Sql Server configuration manager or type services.msc on Run(Ctrl + R)
Add SqlBrowser.exe to firewall exception
Open TCP port 1433 and add it to firewall
Enable TCP, NamedPipe in Sql Server Configuration manager.
Check your public IP using any site like Seemyip.com
Give this IP to your friend along with sql server instance name
On remote machine - enter IP\ServerName with credentials for sa.
OP you just need a dynamic DNS Record (for free at dyndns.org) and then you can create a port forwarding on your Router/Firewall to your SQL server.
That way your SQL Server will be accessible over the internet. Just update your connection string with the dynamic DNS entry that you registered.
This link would be helpful to set the configuration.The link tells how to manipulate connection string according to scenarios.
Here is your:
Server=myServerName\myInstanceName;Database=myDataBase;User Id=myUsername;
Password=myPassword;
I use the following connection string to establish a remote connection in SQL Server:
"Data Source=" + _databaseIP + "," + _databasePort + ";Network
Library=DBMSSOCN; Initial Catalog=SI_CONFIG; uid=sa;pwd=Password1!"
where the _databaseIP and _databasePort are input by the user.
However, although the IP is fixed on the remote machine, the port eventually changes.
To discover the actual port where the server is listening I look for the ERRORLOG file ('c:\Program Files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\MSSQL\Log\ERRORLOG') and search for the line 'Server is listening on [ 'any' 49167' which tells me the port, however, this seems to change randomly after some days or weeks.
I wanted the port to be fixed, or to use another way to connect through the server, in a way which I did not demand the port anymore from the user. Any suggestion is appreciated. Thanks.
It sounds like your SQL Server is configured to use a dynamic port. From the link:
Named instances of the Database Engine and SQL Server Compact are
configured for dynamic ports. This means they select an available port
when the SQL Server service is started. When you are connecting to a
named instance through a firewall, configure the Database Engine to
listen on a specific port, so that the appropriate port can be opened
in the firewall.
To configure your SQL instance to use a specific port instead, open up the Sql Server Configuration Manager and navigate to Sql Server Network Configuration -> Protocols for (instance name). Right-click TCP/IP, go to Properties -> IP Addresses tab, and clear all the entries for TCP Dynamic Ports. Set the TCP Port value for each IP address on which you want to make connections available. SQL will need to be restarted after you save your changes.
I have run into a situation with a C# application installed at two sites where the initial connection to SQL Server is extremely slow. I wrote a test application to verify where the slowdown occurs and it is on the first SQLConnection.Open statement. It was taking about 41 seconds to establish a connection to the server via named pipes. We thought it might be a DNS issue but its just as slow using a TCP/IP connection. After the initial connection is made the connection is pooled and the application responds normally. Both the workstation and the server are decent machines running Windows 7 Pro, Core 2 Duo 3.16 Ghz with 4 gig of Ram. I did find the following article on a microsoft forum:
http://social.msdn.microsoft.com/Forums/en/windowscompatibility/thread/f295994c-5812-4e46-8ac9-f05471d4dd54
Turning off the LLMNR protocol did cut the initial connection time in about half to 21 seconds. However, this is still a long time to get an initial connection to SQL Server. The only things slightly different from our norm is that DNS in this case is done thru a router and not an actual server. This has occurred at only two places so far, others run with no issues. Any help would be appreciated.
Thank You,
Dennis
In front of the server on the connection string, add np:
This becomes Server=np:server\instance and forces the Named Pipes instead of the default of TCP.
I could of probably changed the priority to use Named Pipes before TCP... but I did not want to mess with that on the server.
I saw similar problem but not sure it's the same as yours. In my case, it's not just the C# program being slow to make the SQL connection. It's any tools connecting to SQL server also experiencing the slowness. Also, once the initial connection made to the SQL server, any subsequent connections are fine for a period of time.
The reason was that SQL server was using a number of managed assemblies. It's trying to verify the cerfiticates assigned to the assemblies. It's connecting the crl.microsoft.com. My SQL server didn't have the internet connection. So, it waits for the timeout.
The solution was to make my SQL server to have internet access or disable the CRL checking. You can go to the SQL server machine. Select Tools > Internet Options > Advanced. Check if the publisher's certificate revocation under the secuity node is checked or not. If it's checked, uncheck it.
I tried specifying the connection string with integrated security = false (meaning the user id and password are in the connection string) and encrypt = false (just be be 100% sure SSL encryption is not being used). These specifications did not seem to help and I could not get a connection explicitly using the TCP/IP network library (NetworkLibrary = "dbmssocn"). This could have to do with the server firewall and the port not being open. I switched back to named pipes and put the named pipe network library specification in the connection string this time (NetworkLibrary = "dbnmpntw"). After this change, the connection was made instantaneously.
Establishing an integrated security connection to SQL Server using the IP address (instead of a host name), will prevent Kerberos authentication being used. In this scenario check the connection between the SQL Server and the domain controller.
If you connect using the host name (not the IP Address) Kerbos is in play, in this case you need to check the client machine's connection to the domain controller.
We had the same problem, and it turned out that our remotely-hosted Active Directory server was to blame.
We created a site-local Active Directory server to replicate the remotely hosted AD master and then all of our slow SQL Server integrated security authentication performance issues went away.
I hope that helps.
Yeah when you're using integrated security, Active Directory can be the one to blame, also the overall network since it all depends on it. Another thing I could think of is the edition of SQL Server you're using.
Also, when SQL Server is not being used by long periods of time, it behaves similar to IIS, putting the worker process to sleep, so when you contact the server again, depending on the machine (we can see that these have desktop machines configurations), it will take some time while the worker process gets back to life and is ready to work.
You did check the obvious I take it? That UDP port 1434 is open on the firewall and the browser service is running .... would take about 40 sec to authenticate otherwise.
there are other methods of creating connections to SQL databases. Try finding a tutorial which uses the
sqlconnection myCon = new sqlconnection(details);
myCon.Open()
instead of creating an object to instance the connection.
I don't have a concrete answer but have you tried running SQL Profiler to see what is going on from SQL's point of view?
Also have you tried connecting to SQL using the same credentials as your connection?
On the other hand it may all be much lower level but I always do the easy to check stuff first.
Good Luck.
It sounds like either name resolution is taking a while or authentication is taking a while. After the initial resolution or authentication's occured, then details of endpoints are cached by the server so it doesn't need to perform the lookups again until caches expire.
As an experiment, try ping'ing the server from the client box -- if this takes a long time to resolve the hostname, then you've found the culprit: hostname lookups (DNS or NBNS). Another alternative is to use the host IP address rather than name. So if you've got a SQL Server named instance of bob on server sql2005-01, and this server has an IP of 192.168.200.12, then try connecting to 192.168.200.12\bob instead of sql2005-01\bob.
Authentication's more awkward to resolve, but you might be able to test it with runas on the SQL server box (e.g., runas /user:domain\user cmd to see if you can open up a command prompt as the user you're attempting to authenticate as.
It could easily be a problem with either the connection or the authentication, it is normal that the first connection takes longer as ADO.NET has connection pool to avoid that long connection time.
There are many factors that can influence the speed:
- TCP/IP configuration
- Routers on the server-side
- etc.
Still if you are facing the issue, please see blow resolution:
Root Cause
The issue which we were seeing on Win7 VDIs could be due to the Network hardware device connected with the machine. If TCP/IP scaling is not supported by the network device then the performance will be slow.
Solution
Disable auto tuning level of the TCP. Please follow below steps:
1) Open command Prompt with admin right (Run as Admin)
2) Type “netsh interface tcp set global autotuninglevel=disabled”
3) After running above command restart the machine.
For other information on this command, visit link “http://support.microsoft.com/kb/935400”
I had the same problem. After vigorous research on google and stackoverflow, i changed the client computer's hosts file (In windows,located at C:\Windows\System32\drivers\etc).I entered my host's ip address and server name in this file and Viola!. Things became superfast!
Like everybody in stackoverflow said, it was the computer looking up the servername's address in the DNS service and getting a timeout.
The steps i did follows.Give it a try if nothing else works.
HOW TO ADD AN ENTRY IN HOSTS FILE
1.Open the command prompt and ping your server,where the remote database is located. To do this enter the following command:
ping servername
Here my remote computer name was Juno. So i should ping like this.
ping Juno
This command will ping my server and returns ip address like this.
Pinging Juno [192.168.0.3] with 32 bytes of data:
As you can see the ip address of the server is between the brackets.
Copy the ip address.
2.Now Open the Hosts file with elevated Notepad(Run as administrator).
At the end of the hosts file,there will be some lines like these:
#localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
At the very bottom (here,after the localhost),type # and enter the ip address of the server we just obtained preceeded by server name.
So, the hosts file should look like this.
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
# 169.254.63.1 Juno
Now save the hosts file and restart the Client PC. (For me,it worked instantly without restart.)
Annd there you go!
For more info about editing your hosts file,click here
In my case the answer was:
Try everything with no result.
Remote Desktop to the (non-prod) SQL Server to double check settings.
Close down Visual Studio you left running after doing a quick SSIS job.
Go somewhere quiet and kick yourself.
Open Start -> Microsoft SQL Server 20XX ->SQL Server Configuration Manager
SQL Native Client 11.0 Configuration (32bit) -> Client Protocols -> (Ensure all items are marked as "Enabled")
SQL Server Network Configuration -> Protocols for MSSQLSERVER -> (Ensure only Shared Memory item is marked as "Enabled", others should be "Disabled")
SQL Native Client 11.0 Configuration -> Client Protocols -> (Ensure all items are marked as "Enabled")
Reboot computer
Ensure SQL Services are running and attempt to connect to local MSSQL
Connection should be much more rapid
Developed a Windows application that remotely accesses an SQL Server online. However, the client's ISP blocks port 1433. What are the other options to connect to SQL Server from the windows app?
SQL Server should have a network utility where you can configure the port to be used. Contact your client's ISP to see which ports are open (they may even be able to open up 1433 for you) then configure the server to use that port.
In my install, you select: "Start > All programs > Microsoft SQL Server > Server Network utility", select "Enabled Protocols" then "TCP/IP" and "Properties".
From there you can set the default port to a more accessible one.
You could change the port number that SQL Server runs under, to use a port that is actually open at the ISP.
Since 1433 is the default port for SQL Server, it is a common target for hackers. Some ISPs pick an arbitrary port number to obfuscate this. You may need to find what port number that is from them.
Another option is to use a WCF Web Service hosted in IIS and have your windows app call this service.