I'm running SQL Server 2014 Express and using the SQL Server native drivers for the connection from my VS.net code. These are both on my Win10 machine.
Suddenly, in the last week or so, I've been receiving errors when my code attempts to connect. Of course the dialog doesn't allow cut-n-paste, so helpfully this is correct:
Named Pipes Provider error 40 - Could not open connection to SQL Server
This only happens about 1 in 10 times that I run the app. If I simply stop it and re-run it, it instantly connects. Another machine in the office running Win7 and SQL Server 2012 started showing the same behaviour, but fails all of the time now.
Note: yes, the server is running, the firewall is configured properly, as is the server's connections, the browser is up, etc. It's important to note that these would cause it to fail 100% of the time.
Does anyone have any ideas what's going on? Was there a recent driver update that might cause this perhaps?
Related
I am running an SQL Server 2008 SP2 instance on my work desktop. Recently, after a power outage, I began having issues with the Object Explorer pane (from both local and remote connections). I can query against the databases fine using T-SQL, but if I attempt to initiate any actions using the Object Explorer (Import Data, Update Linked Server, run SQL Agent job), SSMS hangs and I am forced to close the application using Task Manager. Until I reboot the server instance, the Object Explorer will hang indefinitely upon connecting. When it hangs, there doesn't seem to be any unusual network or resource utilization and SSMS.exe does not show the typical "not responding" during a freeze.
The server only hosts data for my own projects, so it isn't anything truly business-critical. As such, downtime is not a real issue. I encounter this hang when accessing the server locally and remotely, so I don't think it's just my SSMS copy. I do have all of the databases backed up, so if necessary I can restore on a new instance (if the issue is corruption), but I wanted to check if anyone had encountered this.
There are three linked servers (2 Oracle, 1 Postgres).
Try executing ssms.exe-log filename and see if you get any more info.
I have been using SSMS and LinqPad both for months to connect to SQL Azure instances without issue. Suddenly this week, linqpad stopped connecting, consistently timing out and displaying this error message: "A connection was successfully established with the server, but then an error occurred during the pre-login handshake. (provider: SSL Provider, error: 0 - the wait operation timed out.)"
At first, it was just LinqPad. But soon after I started experiencing the same issue with SSMS 2012. It showed the exact same error message (slightly different dialog).
I've confirmed that this isn't a firewall rule issue. My IP has been allowed through the SQL firewall for months, and I can still connect using the same credentials using SQLCMD and I can run queries.
Any ideas? Why would SSMS and LinqPad both take a big dump while SQLCMD still works?
I finally found the solution to this (I think I may have found it via https://stackoverflow.com/questions/13420770/pre-login-handshake-error-connecting-directly-to-sql-azure). I installed some completely unrelated software about the time that things stopped working. As it happens, said software also installs - silently - some bundled software that leaves you with custom Winsock LSPs in place, which means the system is then afflicted by an issue reported to Microsoft and addressed in KB 2568167. Fortunately, I didn't have to manually remove the LSPs because I was able to uninstall the unwelcome software (Sendori!).
Did you look at the connectivity troubleshooting guide for SQL Azure?
http://social.technet.microsoft.com/wiki/contents/articles/1719.windows-azure-sql-database-connectivity-troubleshooting-guide.aspx
Have you also installed .NET 4.5 recently/in that week time frame? Have you checked your SQL Connection to make sure that SSL encryption is off?
Yes folks, it's this one again.
"A connection was successfully established with the server, but then
an error occurred during the login process (provider: TCP Provider,
error: 0 - An existing connection was forcibly closed by the remote
host.)"
I'm sorry... I have Google'd this, I have read the other StackOverflow articles on this problem, and I have tried all kinds of suggestions, but nothing works.
Here's a few notes about what we're seeing.
This issue occurs occassionally in SQL Server Management Studio itself (doing any kind of database activity... getting a list of tables in a database, having a look at a Stored Procedure, etc)
It also happens in Visual Studio 2010 itself, when it is trying to get data from the servers (e.g. when creating a .dbml file, etc)
It also sometimes happens in our .Net (ASP, WPF, Silverlight) applications.
Our SQL Server 2005 & 2008 servers are all based on virtual machines in data centres around the world, and we see sometimes this error on each of them. But most of the time, they all work absolutely fine.
When the error does occur, we can just "retry" what caused the error, and then it'll work fine.
We think.. if we have an IIS Web Server in a data centre in a particular city, and it accesses a SQL Server in the same data centre, then we don't see the issue.
We think.. if we connect to the servers, and specify the UserID and Password to use, it causes this error much more frequently than if we just use Active Directory authentication.
Put all that together, and it sounds to me like some kind of network issue.
But can anyone suggest what to look for ?
This isn't a bug in our .Net applications, as even SQL Server Management Studio "trips up" with this error.
It's baffling us.
Just in case anyone else hits this issue, we finally found the solution.
Our company uses Riverbed software to compress data, when it's being passed between locations, and this was somehow causing some connections to get dropped.
Our IT gurus found a configuration setting which finally fixed this issue.
I believe there's a setting in there to turn off compressing results from SQL Server (or something like that). That fixed it for us.
It could be any number of network issues. ANYTHING that prevents the code from reaching the server even for the few miliseconds it takes to make one query.
it could also be the result of a failover. When we went from a single SQL Server to a clustered environment, we'd see this happen during a failover. In this case, it turned out to be our Connection Pooling. In essence, the SQL cluster has a controller and two servers behind it. A and B.
Say our web app is using server A just fine, Connection pooling creates a connection on both sides. The server is aware of it, and the web app is aware of it. Once the cluster fails over to the second server, the web app is aware of the connection but server B is not, so we get an error.
The point is, any possible cause of network issues imaginable may be the cause. DOS attacks on the server, man-in-the middle attacks intercepting and changing traffic. Someone trips on an ethernet cable and it's loose in the jack. You name it, if it can cause a connection issue, it could be the cause.
Your issue also sounds like one we had recently - we also have a virtual environment, wih software that moves VMs from one host to another as needed for load balancing. Every so often, we'd get bombarded with the same error. It turned out to be an issue with the NIC drivers on one of the hosts, so whenever a VM moved to that particular host, errors would occur.
It's really not a programming issue. It's an environment issue, and you need trained professionals with direct access to your environment to research and resolve this.
My problem was that I was inadvertently using a wireless network to connect to our network because the Ethernet cable was faulty. This after repairing SQL Server, running a Winsock reset as recommended elsewhere ...
I am experiencing the same issue and our app interfaces with a several Azure SQL DBs. I believe (same as you) I do not have a bug in the C# code to cause this issue. We've solved it by a simple for loop containing an extra attempts to try to connect to the Azure SQL again if the previous attempt fails and then run the query.
Most of the time everything runs fine but sometimes we can see the loop kicked-in and on the 2nd or 3rd time it executed properly without the below mentioned error. After that we see in the log file the error below for all the unsuccessful attempts:
A connection was successfully established with the server,
but then an error occurred during the login process. (provider: TCP
Provider, error: 0 - An existing connection was forcibly closed by the
remote host.)
Even though this is a less-then-pretty solution, it allowed us to run our app without interruptions. I know you've mentioned that trying to connect again (to introduce some connection-failure tolerance) solves the problem and unfortunately this is the only correct solution I found so far as well.
I should mention that we have tried many debugging strategies to figure this out. Right now it all points to the availability of the database we are trying to connect to i.e.: It happens if the number of allowed DB connections is exceeded. (or so it seems at this time)
Turn off your VPN
My Problem fixed by turn off VPN
It was happening in our code when we were opening the dbconnection for oracle and were passing DBtype as SQL in our database object.
in my case - the error was Microsoft first suggestion:
Client is connecting with an unsupported version of the SQL Server Native Client.
In our case, We got this error when we updated sql server to sp3. We were not able to connect to the database from SSIS package.
We updated the native client and configurations. We were able to connect.
link to download the native client - https://www.microsoft.com/en-us/download/confirmation.aspx?id=50402
Link for configurations settings and further troubleshooting - https://learn.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms187005(v=sql.105)
Hope it helps.
Cheers!
Had the same type of issue. In my case it was a bit more complicated... I could connect to “ServerA” from “ServerB” via SSMS, but it would fail with sqlcmd. The error was the same:
Sqlcmd: Error: Microsoft SQL Server Native Client 11.0 : TCP Provider: An existing connection was forcibly closed by the remote host.
I could also connect from “ServerC” with both SSMS and sqlcmd. The following are the versions on the VMs:
ServerA: Microsoft Windows Server 2012 R2 Datacenter / Microsoft SQL Server 2012 (SP3-CU10) (KB4025925) - 11.0.6607.3 (X64)
ServerB: Microsoft Windows Server 2012 R2 Datacenter / Microsoft SQL Server 2012 - 11.0.5058.0 (X64)
ServerC: Microsoft Windows Server 2012 R2 Datacenter / Microsoft SQL Server 2012 (SP3-CU10) (KB4025925) - 11.0.6607.3 (X64)
Bottom line was the “unsupported version”. I noticed a mismatch of “sqlncli11.dll” between ServerC and ServerB, so I copied it to the System32 folder. After this, sqlcmd worked like a charm. Below were the versions in my case:
Failed:
FileVersion: 2011.0110.5058.00
ProductVersion: 11.0.5058.0
Worked:
FileVersion: 2011.0110.6607.03
ProductVersion: 11.0.6607.3
I was working on 2 projects at the same time (on 2 different machines) and both used SQL Server.
When i disconnected SQL with 1 machine the errorMessage went away. Probably you can mess around with IP-adresses too to fix the problem.
In my case I was seeing this error intermittently from a .Net application connecting to a SQL server located in the same server room. It turned out that some of the databases had auto close turned on which caused the server to close the connections in the pool. When the application tried to use one of the pool connections that had been closed, it would throw this error and I saw a log message on the SQL server that the database it was trying to connect to was being started. Auto-close has now been turned off on those databases and the error hasn't been seen since.
Also, having auto-close on is the default behavior for SQL Express databases and these were originally created on an Express instance during testing before being migrated to the production server where we were seeing the errors.
this answer is for those how have this problem with Azure Sql server database.
It happens when you reach mat pool
first remove Persist Security Info=False from connection string
second check your database plan in azure portal and increase the PTUs of your database plan.
In SSMS "Connect to Server" screen click Options, then on "Connection Properties" TAB change "Network protocol" to "Named Pipes"
Try this -
Click Start, point to All Programs, and click SQL Server Configuration Manager.
Click to expand SQL Server Network Configuration and then click Client Protocols.
Right-click the TCP/IP protocol and then click Enable.
Right-click the Named Pipes protocol and then click Enable.
Restart the SQL server service if prompted to do so.
I have had this issue a couple of time already, and I've fixed by reducing the MTU size. Often 1350, 1250, etc on my network interface.
We have a bunch of VB6 applications that access two different database servers (both 32-bit windows 2003, one SQL Server 2000, one SQL Server 2005). About every ten minutes or so, we are getting a few errors:
[Microsoft][ODBC SQL Server Driver]Timeout expired
[Microsoft][ODBC SQL Server Driver][DBNETLIB]SQL Server does not exist or access denied.
[Microsoft][ODBC SQL Server Driver]ConnectionRead()
This is happening on more than a dozen different computers at random times. We also have IP phones that all run through the same network and those are not having any problems. We can also VNC into a users computer and reproduce the error they were getting, but VNC still continues to work. Email also works. It just seems to be an ODBC connection to SQL Server that causes the issue. The errors happen for both of our SQL Servers. We have scoured google, but haven't been able to come up with a solution. Is there anything we can try to diagnose the problem? Is there any fix out there?
Update:
We have no internal firewalls on either the servers or clients. We connect through TCP/IP via the dns name of the server (also have tried IP address).
One server has Windows 2003 SP2 and the other doesn't.
The strange thing is that it has worked fine for years and now all of a sudden these errors are happening. Nothing has changed on those servers for quite some time. That leads us to beleive it is a bad switch, but that seems unlikely since nothing else (email, phones, vnc, file server, etc) all work without problems.
Take a look at this Microsoft Knowledge Base article.
Some problems occur after installing Windows Server 2003 SP2
I would also suggest that you switch to an OLE DB provider. In my experience, it's faster than ODBC and more reliable too.
Connection Strings
Scroll down to: SQL Native Client OLE DB Provider
Are you using non-default instances? Or do you have internal firewalls?
We changed to "server.fqdn.tld\instance,port" to avoid this exact (IIRC) intermittent connection issue from clients behind internal firewalls.
Only SQL connections were affected.
We never did figure out why this was happening. We upgraded our server to SQL Server 2008 and the error messages stopped.
I recently came across a very similar problem and posted it here.
ScottE found the solution.
I have a desktop, and a Laptop. The Desktop has Windows 7 64-bit and the Laptop has Vista Ultimate 32-bit. On both machines I have SQL Server 2008 Standard installed.
On the laptop, I open SQL Management Studio and try to connect to the SQL Server on the desktop. It times out.
With SQL Server Config Manager I Enabled TCP/IP and Named Pipes for the client protocols.
In SQL Management Studio, I right clicked on the Database Engine, went to properties, and allowed remote connections. I also created a sql server login named "testuser" and a password. I then added that user as a login for my database and made them the database owner.
I could not figure out how to allow connection to my db throw the windows firewall, so I turned it off.
What am I missing? I made the same changes on my laptop, and I can connect from the Desktop to the Laptop in Management Studio?
Do you have a checklist?
Thanks.
UPDATE:
I turned off antivirus. Ran NetStat -a and the listener is listening.
If your login attempt takes about 30 seconds to timeout, then it's some kind of network connectivity problem (or SQL isn't listening properly). A permissions problem would come back after a few seconds, so the long wait says it's connection-related.
If you run "NETSTAT -a" on the server, so you see SQL Server listening on port 1433? If not, then maybe the SQL TCP Listener isn't configured properly on the server - there should be events in the Windows Event log to this effect when the SQL Service starts up.
Please edit your question with the results and we can go from there.
Try using Telnet to see if the laptop can see the desktop via port 1433.
Open a command prompt on the laptop and enter:
telnet DesktopNameOrIPAddress 1433
Press Enter, and you should either see a connection failed error, or a blank screen. If you get the blank screen, the connection was established. Press CTRL-] to break out of it, then type "quit" and enter to quit.
If the connection failed, attempt to resolve the general network issue with port 1433 before bothering to use the SQL Server tools.
If you have any other anti-virus software running, it may also have a firewall built in. I know that McAfee does, for instance. Check for that.
You've probably already thought of this, but have you checked that the server is configured to allow Mixed Mode Authentication? I have not had access to 2008, but I seem to remember that at least one of the previous versions was configured to disallow sql logins by default.
I assume you already did what you have to do on the OS level. Or maybe tried to link the server to see if you can actually traverse your network. Let me suggest a quick test. Check if you can actually test connectivity by creating a Universal Data Link. In case you don't know how to do this, create a new text file in your desktop (or anywhere) and change the .txt file extension to .udl; then just open it. See if your other server is "viewable" over the network (Don't forget to change the Provider to OLE DB Provider for SQL Server).
Is the SQL Browser Service running on the server you are trying to access? (By default this is disabled, and you'll need that to access SQL Server remotely)