Similar to another couple of questions I've seen, I'm in the dark place of having no choice other than to connect to MSSQL from Django.
I'm intermittently (but around 50% of the time, the rest it works fine) getting the error;
django.db.utils.Error: ('[08S01] [Microsoft][ODBC Driver 13 for SQL Server]TCP Provider: Error code 0x274c (10060) (SQLGetData)')
Note, I also get this one sometimes;
django.db.utils.Error: ('08S01', '[08S01] [Microsoft][ODBC Driver 13 for SQL Server]TCP Provider: Error code 0x68 (104) (SQLGetData)')
I think it's network related, I've previously tried swapping out pyodbc versions, swapping between FreeTDS and Microsoft driver for unix, and trying pyodbc and pyodbc-azure.
The machines in question are Vagrant boxes on a private network with fixed IPs (Ubuntu 16.04 and Windows 8), SQL Server is SQL Server Express 2016.
I can't even work out how to find a more detailed log on the Windows side to work out why/how it keeps dropping/closing the connection. Note - I've looked in the SQL Server and Windows event logs and they don't seem to be picking anything up.
Here are some useful links based on the error codes logged:
10060
An error has occurred while establishing a connection to the server.
When connecting to SQL Server, this failure may be caused by the fact
that under the default settings SQL Server does not allow remote
connections. (provider: TCP Provider, error: 0 - A connection attempt
failed because the connected party did not properly respond after a
period of time, or established connection failed because connected
host has failed to respond.) (Microsoft SQL Server, Error: 10060)
Generally, you can fix this by navigating to the SQL Server instance and making sure remote connections are allowed. There is a configuration setting in SSMS for this. You also want to make sure the server is set up to use integrated mode security. i.e - windows/ad credentials and sql server credentials. You can define a SQL server user not bound to a user windows identity.
I have an old VB6 application that establishes a connection to the SQL Server and uses it throughout the lifetime of the application.
We recently upgraded the back end to SQL Server 2016 (from 2005) and noticed an odd issue. If the user leaves the application idle for several hours, and then tries to do anything having to do with the database, they get run-time error -2147219450 (80040806) or Connection Failure. The application does check the ADODB.Connection.State and it always reports that the connection is open. We are seeing this error pretty consistently on multiple, pretty diverse (in terms of OS versions) workstations.
I haven't seen anything on Google relating to this. Can someone shed some light on this issue?
I was getting this issue with this driver only when connecting to sqlserver instance on my local machine. Seemed like there was a bug in the shared memory client protocol. Switching to TCP for local connections (Turning off shared mem and named pipes) solved the problem.
the error i was getting was
Microsoft OLE DB Provider for SQL Server "Connection failure" SQL State: 08S01
I am trying to create / modify a system data source for my application which needs to connect to our Microsoft SQL Express 2014 database through an ODBC data source.
The connection used to work before we enabled the SSL encryption flow but,
now that we have an encrypted link, the connection does not work anymore.
Here are some details:
We run Microsoft SQL Server express 2014 SP1 with the latest cumulative update (CU #3) (which was necessary so that we could deactivate SSL 3.0 and TLS 1.0 and run only with TLS 1.1 and TLS 1.2)
The database instance is a named instance, configured to run with a TCP/IP connection and a fixed port.
We enabled the "Force Encryption" option and configured the certificate through the "Sql Server Configuration Manager"
We can successfully establish a connection to the database either using Management Studio or the SQL command line utility
We disabled all usage of SSL/TLS prior to version TLS 1.1 done through Microsoft Schannel. This required us to update SQL Express 2014 SP1 to the latest cumulative update (CU #3)
The ODBC data source we try to configure (through ODBC data source Administrator) is a "System DSN" and uses the "SQL server" driver and target the exact same server name as the one working in management studio (and whose server name corresponds to the machine FQDN which is reflected in the certificate CN value)
The Version indicated for the SQL Server ODBC driver is "Microsoft SQL Server ODBC Driver Version 06.03.9600"
I am testing the connection directly through the ODBC data source Administrator tool.
The first test I runs are run on the exact same machine as the one hosting the database server.
We get two consecutive error message in the Microsoft SQL Server Login:
Connection failed:
SQLState : '01000'
SQL Server Error: 771
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]ConnectionOpen(SECDoClientHandshake()).
Connection failed:
SQLState : '08001'
SQL Server Error: 18
[Microsoft][ODBC SQL Server Driver][TCP/IP Sockets]SSL Security error.
I went through all the literature I could find but cannot find a solution.
EDIT 27/01/2016 16:30
Following erg suggestion, I tried to use the last MS SQL Server Native Client version (11.00.2100 on my system), but it still does not resolve the issue. I experience another issue though (whether or not I force the strong encryption on the client side results in the same error):
Running connectivity tests...
Attempting connection
[Microsoft][SQL Server Native Client 11.0]TCP Provider: An existing connection was forcibly closed by the remote host.
[Microsoft][SQL Server Native Client 11.0]Client unable to establish connection
TESTS FAILED!
So, I finally got it working after struggling a little bit more.
First of all, it appears that there is another CU available (CU4) for SQL Server Express 2014 SP1.
I did download it and install it, but it did not resolve my problem: as soon as I deactivated TLS 1.0 and below version ODBC did not work.
Strangely, though the CU3 and installation of .NET 4.6 allowed me to successfully log in in Management Studio, when I tried to execute
the xp_readerrorlog query, it actually failed.
What I did to solve my issue was to follow malthus's answer on another related stack overflow question
https://dba.stackexchange.com/questions/93127/sql-server-service-won-t-start-after-disabling-tls-1-0-and-ssl-3-0 (3rd answer from the top).
I therefore activated the local security policy on my computer and managed to get the links to my SQL db working.
Now, I got IIS working along my own service and client working.
BTW, if somebody needs a more user friendly way of activating SSL/TLS version(s) and cryptographic algorithms on Windows, I stumbled uppon a nice GUI application which does not required to use regedit for it:
https://www.nartac.com/Products/IISCrypto. It's free and I am not a a Nartac Software employee, manager or shareholder.
I hope this will help!
EDIT Feb 25, 2016
It looks like the latest cumulative update (CU5 available at
https://support.microsoft.com/en-us/kb/3130926) removes the need to
activate the FIPS option for the System Cryptography.
I discovered this since I had to deactivate FIPS to enable another required
functionnality while still relying on a TLS 1.2 connection. Indeed, it
appears that activating the FIPS option for the System Cryptography prevents
.NET Framework to successfuly make use of some system algorithms (such as
SHA256Managed).
In addition, according to some discussions seen around the web (i.e.
http://blogs.technet.com/b/secguide/archive/2014/04/07/why-we-re-not-recommending-fips-mode-anymore.aspx)
it is not recommended to activate FIPS (except to strictly comply with
some governmental recommendations) since it breaks applications
relying on non-FIPS validated implementations of cryptographic
algorithms, which, however are provided in Microsoft system libraries.
Today I could not log into my local SQL Server 2012 instance with the following 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 - An internal error occurred.
(Microsoft SQL Server, Error: -2146893792)
I found many similar questions here and on the forums, but nothing helped. Please notice that in my case it just says
0 - An internal error occurred
There are no errors in Event Viewer;
I don't use Encrypted Connections;
In SQL Server Configuration Manager, Force Protocol Entryption is set to False, Trust Server Certificate is set to Yes (Originally it was No, but in both cases it didn't work);
I CAN connect to SQL Server using UDL;
I tried to re-install SQL Server with all related components;
Tried to uninstall .NET 4.5;
In SQL Management Studio, in connection properties, Encrypt Connection is unchecked.
It worked fine yesterday, I have not installed any software since then.
check that TCP/IP protocol is not enabled for clients. Without TCP/IP protocol you can not access the sql server from other clients. Following is the method to enable the protocol.
Go to the: Start-->Programs-->SQL Server--> Configuration Tools-->SQL Configuration Manager.
Expand the SQL Network Configuration and click on the PROTOCOLS node
Right click on TCP/IP and open up the PROPERTIES panel
Select the IP ADDRESS tab
http://sqlanddotnetdevelopment.blogspot.in/2013/07/a-connection-was-successfully.html
In our case it was the problem with the SSL/TLS. We just disabled tls 1.0 to make sure we were compliant with PCI DSS but it stopped SQL Server. Then we had to install one update from Microsoft and then did the disable thing using IISCrypto instead of using the registry. Here's the steps we followed:
https://www.itechtics.com/connection-successfully-established-error-occured-pre-login-handshake/
I got this error connecting to localhost with the newest version of Microsoft.Data.SqlClient.
Turns out that Microsoft really wants you to encrypt your database, for security.
This can be fixed client side by changing the connection string, by adding an Encrypt=False parameter, eg:
SERVER=.\SQLEXPRESS;DATABASE=MyDatabase;Integrated Security=True;Encrypt=False;
See Rick strah's blog post on the subject
In our case same error occurred due to spn not set.Try checking if spn is set. As others suggested in comments you can see ring buffer entries which holds more info .if you are able to repro more often try running netmon or wireshark in parallel
None of this stuff worked for me.. in the end I had to install the cumulative update for SQL Server 2014 SP1
SQL Server Cumulative Updates
In my case the error was fixed by adding "Encrypt=False" like this:
Server=localhost\\SQLEXPRESS;Database=*YOUR_DATABASE*;Trusted_Connection=True;Encrypt=False
Disable TLS 1.2 protocol and enabled 1.0 /1.1 . Re-installed SQL server post restarting the server
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.