I'm running into a frustrating problem with a subset of users. I've got a small client application that runs on their local machine and throws an error when trying to connect to a remote database server.
Here's the error and what I know:
[DBNETLIB]SQL Server does not exist or access denied
There are lots and lots of other instances of this I've searched through, but all of the ones I've found point to a server-side issue (not running, firewall blocking port 1433, etc.). In my case, the problem is only occurring on a subset of users systems, so I have to assume it is something specific to their systems.
Credentials for the SQL Server are using a service account, so it's the same for all users, ruling out some users being properly set up but not others
When the error occurs, the response takes a long time to come back, which would lead me to think that the error is related to a timeout and not denied access (this might be a bad assumption)
The error occurs no matter whether I use OleDBConnection or ODBCConnection
The error occurs if I use a connection string built on the fly or a DSN I created. The DSN points to the same SQL server that I can't connect to via my application and uses the same {SQL Server} driver. I've also tried it using the SQL server native client 11 and get the same issue.
I can create a user DSN on their machine and successfully test the connection to the server with it
I can use the user DSN to link a table on the remote server in a Microsoft Access database on their machine and that works.
I compiled my code 64 bit only as well as trying 32 bit to see if anything helped. It did not.
I'd assume it has to be something in my code, except it works for multiple other users. So some combo of my code plus their system configuration has to be at play, right?
Here's the entirety of the connection logic:
dim DBConnection as OdbcConnection = New OdbcConnection()
DBConnection.ConnectionString = "DSN=<DSN name>;Uid=<username>;Pwd=<password>"
DBConnection.Open()
It times out on the DBConnection.Open(). I looked at the ODBC trace logs comparing my own system's trace to theirs, and it looks identical up until the point where I get a successful connection back and they get a timeout.
Any thoughts? I'm stumped.
Your point #1 is most likely the cause (port 1433 is blocked), but this is on the client side, not the server. Chances are, they are running firewall software (such as Windows Firewall) that is blocking outbound SQL Server connections.
If it's Windows Firewall, there is a built-in wizard that will allow you to allow outbound SQL Server connections.
Regarding this:
When the error occurs, the response takes a long time to come back, which would lead me to think that the error is related to a timeout and not denied access (this might be a bad assumption)
When the server address can't be found or can't be connected to, most of the time, the client will take a while before throwing the "connection" error. It won't throw the error immediately.
Other possibilities:
VPN
Server name vs IP address - I've had users that could NOT ever connect to a SQL Server box using the server name, because of various network configuration issues, either on their devices or because of network configurations at their location. Try using the IP address (or vice versa).
We have a client that connects to SQL Server using Windows authentication. They connect using the server name and port number (not 1433).
All our software installations thus far connect to SQL Server using SQL Server authentication, connecting with server name, user name and password.
I am trying to setup a test on my computer to see whether I can connect with our software using the setup used by this client, in other words Windows authentication, with server name and port number. The port number is what is new to me here.
The problem I am having is that I can connect successfully regardless of the port number of the SQL Server installation, and what I pass in as a port number from our software. So I am obviously doing something wrong, or misunderstanding how this works. Any help would be appreciated.
My first step was to open SQL Server Configuration Manager > Network configuration > Protocols for my instance > TCP/IP > Properties. I then opened the IP addresses tab, and changed the TCP port to 41000 (I sucked this number out my thumb) on all the IP1 - IPAll sections. The TCP dynamic port setting is blank for all these. I applied, saved and restarted the server.
In the DbExpress TSQLConnection connection parameters, I pass in:
TSQL1connection.Params.Add('OSAuthentication=True');
TSQL1connection.Params.Add('HostName='+SQL_server_name);
TSQL1connection.Params.Add('Port=123');
It doesn't seem to matter what I put in the port number, or whether I leave the port setting out altogether; I always manage to successfully connect.
I want to have it successfully connect only to the port number specified.
I am using SQL Server 2014 and Delphi XE8.
I don't know TSQLConnection, but I do know a bit about TCP/IP, and I suspect that the issue here is just a misunderstanding about ports. There are always two ports involved in a connection, in this case the server port and the client port. They are not the same. The 41000 is the server port in this case, and I assume that 123 is the client port. That is perfectly fine to establish a connection, and that is why it doesn't matter what port number you put in.
In terms of solving your problem, you need to reject the connection at the SQL Server end. The server will know the client port after the connection, but whether you can access that data and force a rejection, I am afraid I do not know.
I'm new to SQL related matters so please bare with my lack of knowledge and asking a question which has been asked countless times before.
I have to connect to a SQL database server which is located at a remote location at xxx.xx.xxx.xx:3306, but every time I try to connect I get the same 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: TCP Provider, error: 0 - No connection could be made because the target machine actively refused it.)"
I get this same error whether I try to connect using SQL Server Management Studio or in a C# program via:
SqlConnection myConnection = new SqlConnection(...)
myConnection.Open();
I've tried it on two different computers, both on the same home network. I've had a look at the SQL server configuration manager on the computer which I installed SQL Server on, enabling TCP/IP and fiddling with the port values settings, but I'm guessing this is just for configuring an SQL server on my computer and irrelevant to connecting to a remote one. I shouldn't even need to install SQL server to do queries on a remote server anyway, right?
I've turned off my Windows firewall and my router firewall, though ShieldsUP still says
Port: 3306
Status: Stealth
Your system has achieved a perfect "TruStealth" rating. Not a single packet — solicited or otherwise — was received from your system as a result of our security probing tests. Your system ignored and refused to reply to repeated Pings (ICMP Echo Requests). From the standpoint of the passing probes of any hacker, this machine does not exist on the Internet. Some questionable personal security systems expose their users by attempting to "counter-probe the prober", thus revealing themselves. But your system wisely remained silent in every way. Very nice.
I read that this is irrelevant as well, since I'm not the one hosting the server, but when I was given the address, I was given the port as well, so I must have to do something with it. I'm just not sure what. My understanding of ports really is quite shaky.
I've been trying this for over a day now, and I can't think of anything more I can do.
EDIT: I fixed the problem. I had to use MySQL, not MSSQL. Doh. Sorry guys.
If you are sure the remote SQL Server is running on port 3306 (otherwise I'm not sure why you talked in the question about that port specifically), try the following connection string:
user id=username; password=password;
data source=123.45.678.90,3306;
initial catalog=dbname;
Network Library=dbmssocn;
I think without the port you'll have trouble if the other end has disabled the SQL Browser service. You should also make sure it isn't a named instance, in which case you may need:
user id=username; password=password;
data source=123.45.678.90\InstaneName,3306;
initial catalog=dbname;
Network Library=dbmssocn;
First of all the database is local or distant ?
The you have to ensure that your connection string is well written.
Here's an example of a valid connection string :
Data Source=myServerAddress;Initial Catalog=myDataBase;User Id=myUsername;Password=myPassword;
More about connection strings :
Connection Strings
Now if everything is set up correctly you have to enable remote connections to SQL Server on the host. To do so please refer to this article :
Enable SQL Server Remote Connections
Just go to ypur serveices and check whether your SQL Server (MSSQLSERVER) is running.Most of the time this error happens when SQL Server (MSSQLSERVER) is stopped.
Then select it right click and click start.problem solved !!!
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.
I am getting an error while connecting sql express server 2005 over the network.
An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections.
I have tried following things.
1. Allow remote connection along with both TCP and named pipe checked in both (target and initiator machine) in surface configuration manager.
2. sql browser is on automatic mode and running on both the machines.
Still I am not able to connect to machine.
I could see the server name (without "/sqlexpress") with the list but not able to connect.
I think if it could start showing TargetServer/sqlexpress then I could connect it easily.
Please guide me if I am missing anything.
Thanks in advance.
Anil
This is a pretty common problem, because by default, the remote support is turned off, and firewalling is enabled, so turning on the service doesn't always open the port.
Have a look at the answer to this MSDN question
Also check the authentication method - this is usually my problem. Eg. Windows Authentication across OS types or different usernames.