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
Related
Steps that I've taken so far
I've disabled the firewall and configured the SQL Server to allow remote connections
Verified if the hybrid connection manager has the connection established
Modified the connection string to specify the TCP ports
Please let me know if you have any further suggestions.
Thanks for the replies, I've finally figured it out.The mistake i was making was that i was specifying the SQL Server Name AND port number(433 in my case) ONLY while deplying to azure and in my code behind the connection string only had the server name mentioned.
However when I updated the connection string in my code behind to include the TCP port, i was able to successfully run the app in conjunction with the Hybrid connection to query results from the SQL Server.
Recently I also worked on Azure hybrid connection and have made a list of all the possible problems that I faced. One of the following may be the cause:
Hybrid Connection may only work with Default Instance of SQL Server and may fail in case of using a Named Instance. Even if the named instance is configured to use static TCP port yet might not work with the Hybrid Connection.
The possible reason might be either your named instance might be listening on the same TCP port as your default instance. As hybrid connection uses port for communication so in case when multiple instances are listening on the same port then hybrid connection might communicate to any of the one regardless of what instance you have supplied in your named instance.
In order for hybrid connection to work you need to enable TLS 1.0 on your on premises machine for both server and client. You need to add following registery value (if not already added):
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0]
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
The hybrid connection will only work if the connection string uses SQL Authentication i.e., specifying the username and password in the connection string. Thus you can not use Windows Authentication.
Although you do not need to open any firewall ports for inbound connectivity yet you are required to allow outbound connections to the following list of ports:
9350 – 9354,
5671,
80,
443
Azure hybrid connection requires Windows 8/Windows Server 2012 or later to work with. The reason for this is that hybrid connection uses Web sockets that are not supported in the earlier windows version than these. Although you can use the classic hybrid connection (now depricated) to work with the earlier Windows.
It is preferred to use the Fully-Qualified machine names for the endpoint and not the IP address. In cases where the IP of your machine is unlikely to chnage there it might have no effect but in cases where the IP might change, you shuold use the machine name and let the HCM handle everything else for you.
Also a very comprehensive walkthrough of creating a hybrid connection can be find here
Hope this solves your problem.
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've noticed that if I don't supply a port when I build a connection string I can still connect to SQL Server via a named instance that looks like [SERVER][INSTANCE_NAME].
Is sqlclient automatically gathering the port number for me? Do I have to concern myself with port number even if the instance is the default instance?
I'm sorry if this question seems novice. Google just hasn't turned anything up for me.
Thank you!
One thing to keep in mind though is that if you have multiple instances of SQL Server installed on the same computer, then each instance will use a different, random port number (although, a specific port number can be specified using the SQL Server Configuration Manager, right-click on the service & select Properties).
If you're connecting via the instance name though, and the SQL Server Browser service is running, it will redirect all requests to the appropriate ports automatically.
Another thing to keep in mind, is that the Express Edition (i.e. the free version) of SQL Server doesn't enable the TCP/IP protocol by default. I know this is the behaviour with older versions of SQL Server, but this may have changed in newer versions.
Well usually the default port that SQL Server listens on is 1433 so you dont need to specify the port number in the connection string.
There is a nice article that gives some more info on the subject:
http://benchmarkitconsulting.com/colin-stasiuk/2009/02/02/what-tcp-port-is-sql-server-running-under/
I have a simple piece of code in a .NET console application that tries to open an SQL connection to a server:
using (SqlConnection connection = new SqlConnection("<my connection string>"))
{
connection.Open();
}
It works perfectly fine on my Windows 7 machine, but on my other machine running Windows XP x64 the call to Open() hangs indefinitely.
Any ideas why this is happening or how I can diagnose the cause? I am running the program from an administrator account on both computers.
EDIT: Ok, it seems to be a firewall issue. I've connected my Windows 7 machine to the same internet connection as the Windows XP machine and now it hangs too... what ports do I need to open to let SQL traffic through, and how do I go about opening them?
EDIT: In case anyone's interested, my network admin was blocking outgoing traffic to port 1433 out of fear of the Slammer worm ...
Since I can ping and attempt to connect to database2.ehost-services.com (though I received a Login failed), let's try to simplify your connection string:
Data Source=database2.ehost-services.com;Initial Catalog=myDatabaseName;User ID=myUser;Password=myP#ssword;
EDIT
To answer your question regarding why your connection string did not time out, MSDN describes the pooling attribute of the connection string as follows:
When the value of this key is set to
true, any newly created connection
will be added to the pool when closed
by the application. In a next attempt
to open the same connection, that
connection will be drawn from the
pool.
Connections are considered the same if
they have the same connection string.
Different connections have different
connection strings.
The value of this key can be "true",
"false", "yes", or "no".
So I'm thinking perhaps your connection instance wasn't actually pooled yet to time out.
EDIT
From your error message it looks like you're using NAMED PIPES instead of TCP/IP. Maybe this can help you out (use SQL Server Configuration Manager to select your protocol). Check under [SQL Native Client 9.0/10.0 Configuration] and you should see a list of protocols. Make sure TCP/IP is listed with an order before Named Pipes and is also ENABLED. For example, my order of 1 - 3 is Shared Memory, TCP/IP, Named Pipes, and VIA is disabled.
EDIT
Try creating an Alias with TCP/IP protocal selected and connecting to your alias? You can do this also using SQL Server Configuration Manager.
EDIT
As the OP has resolved the issue, I did make the comment on someone else's answer:
A security policy that blocks outgoing
would have to be explicitly created
and SOB, that's what it was - network admin blocked outgoing traffic on port 1433. Glad you figured it out!
Are you sure your database server is accessible from both of your PCs? Have you tried connecting to it from the problematic system using another tool?
And how long have you let it run?