I'm running out of ideas so checking if anybody can shed some light.
2 tier Client-server application
SQL Server 2005
Workstation: Windows XP
Client-Server Application 1 uses SQL OLE DB Provider. (Provider=SQLOLEDB.1)
Client-Server Application 2 uses SQL Native Client. (System.Data.SqlClient.SqlConnection)
Somehow, application 1 works well but application 2 needs to have Timeout in connection setting to be 30 seconds to make it work.
Using a tip I learned from JohnnyCoder's Database Connectivity Test with UDL File, I tracked down the problem is somewhere around driver. When I try Microsoft OLE DB Provider for SQL Server, it connects immediately. When I try SQL Native Client, it doesn't take long. It fails even it I set connection timeout to be 60.
Both of the applications work well on other installations but not on one specific site. So it has to be related to some environmental settings such as security, firewall, etc.
I tried installing new SQL Server 2005 Native Client on workstation. No luck.
So my question is:
Why does Application 2 ever make it work when the client actually cannot connect? Is there internal logic to use OLE DB when SQL Native Client timeout happens?
What else would you take a look?
Answer: their network firewall blocked TCP/IP packets.
As a result, SQL Native Client timed out with TCP/IP after 20 seconds and then tried Named Pipe which made it work.
Related
Our .Net webservice provides data for about 1000 users and 3000 request per seconds.
If it connects to a database reside on LAN, every thing is OK. But when it connects to a database through The Internet, and naturally, connection will some times not stable and it lead to dead connections. In client's connection pool, connections are still there and on the server also but they are dead already. No connection will be created after that because of full connection pool.
If that happend, we have to reset IIS :( and it happens a lot.
We are using free version of DotConnect 7.3.132.0, Oracle 10g and webservice written in .Net 2.0.
Please help :(
We move our webservice to the same LAN of DB. Every thing is fine.
I have an ASP application sitting on 2 servers, using a db in SQL Server 2012. The SQL Server uses AlwaysOn Availability groups but when these failover the client connecting to the ASP.NET application terminates. I have looked into the SQL driver which as it turns out the app is using SqlClasses so not using ODBC driver (from what I have deduced I presume that logic is sound but correct me if I'm wrong).
Another suggestion has been made that I load balance the 2 app servers and that will seamlessly allow failover underneath without the client loosing connection, is this a viable way to go? We don't have much control over the applications code to ask it to try the connection again after failing....
Many thanks in advance.
Try defining the failover partner in your connection string.
Data Source=myServerAddress;Failover Partner=myMirrorServerAddress;
Initial Catalog=myDataBase;Integrated Security=True;
And also check out MultiSubNetFailover property in .NET 4.5
I am trying to connect an ASP.NET 2.0 application hosted on a client machine to an SQL server 2000 instance which is installed on a domain controller running windows server 2003 (I appreciate this is not best practise, but it is something I cannot change). I am using SQL server authentication, not Windows authentication.
During debugging, the following error is displayed at the point the 'connection' is attempted within the web application (not on running any object within Sql Server):
"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. (provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)"
I have done some research, and have checked a variety of things:
1) I am certain the conection string is correct - in fact I built a little Windows app that uses the same connection information and connection succeeds...
2) This is limited to the web application - a windows application running on the remote client machine connects just fine using the same connection string (see 1).
3) The firewall settings on both computers do not prevent the connection (see 1).
4) I can ping the windows 2003 server (see 1)
5) The SQL Server credentials definitely have the rights to the objects needed
6) If I (temporarily) put the web application on the windows server 2003 and run it, it loads and runs fine (using a browser on a separate machine, or on the client machine I am trying to connect) - suggesting this is only an issue with a remote connection, and confirming the connectivity between the machines again, and also confirming the necessary security right of the SQL Server user.
7) I can start query analyser on the client machine and using the same SQL server credentials, can run the same queries on the target database just fine.
Stumped. Please help!
You need to go into the SQL Server Configuration Manager and make sure the Named Pipes option is turned on. It is not turned on by default when you install SQL Server.
Because of the research I did in the original question covering the ability of a windows app to connect but not the ASP.NET app to connect from the same machine, and the confirmation the web app was working on the server itself, I was convinced SQL server was set up correctly, that connectivity and firewalls were not a problem - it must have been a difference in the security credentials of the windows app versus the web app.
The windows app runs in the security credentials of the logged on windows user and authenticates using that, whereas the webapp runs in a restricted account and does not pass these credentials over when connecting to SQL server by default. I simply added to web.config, which impersonates the user account within which the web app runs, and it all worked!
Problem solved.
I developed a web site using Sybase PowerBuilder V12.0 Classic and the output is deployed and converted to ASP.Net (ASPX) web pages.
The Database connection is configured and used properly as the data is displayed in the web application using DataWindow Objects and is a direct connection with sybase Database Server using Dsedit Tool and No ODBC is used.
I edited The Sybase Databse configurations related to remote servers and connections to be more than the default value which was 25 although the real number of users will not exceed that in the same time.
Recently I received an error message when some users connected to the web site and after making valid logins:-
The Error Message is:-
Maximum number of connections already opened
ct_connect(): user api layer: external
error: The maximum number of
connections have already been opened.
I am confused about the causes of that error as I think I had made all configurations needed and I checked evey option and setting related to the Number of Connections in The Sybase Database server, The Application Deployment Settings in Sybase PowerBuilder V12.0 Classic, and The IIS Settings.
I use Windows Server 2003 and the IIS version is 6.0 in the Web Server.
I appreciate any suggestion or hint to solve that problem and Thanks in Advance :)
The error message says it all really. There are too many concurrent connections to your database.
Perhaps your application doesn't close all of them. If you do not close database connections, connections can remain opened for some time.
Now, I never developed for Sybase, but that is what is usually the case with MSSQL server when this error occurs.
We are upgrading from an environment where the development web server, the SQL Server 2005, and SQL Server data are all on the same machine, a Windows XP Machine. We are upgrading to having the web server on one Windows 2008 server, the SQL Server on a 2nd Windows 2008 Server, and to Server to a Windows 2008 server, nd the data on a SAN.
Now we are getting the error message:
A connection was succesfully established with the server, but then
an error occured during the login
process. (provider: named pipes
provider, error 0, no process is on
the other end of the pipe.)
The network guy thinks it is a problem with the connection string:
<add name="CNString"
connectionString="Data Source=WEBSERVER;
Initial Catalog=PCIdb;
User ID=sa;Password=pass;"
providerName="System.Data.SqlClient"/>
Can anyone help out here?
Is your SQL Server really called WEBSERVER (DataSource="WEBSERVER") ??
Also, I would never EVER use the sa account in a connection string - NEVER, period. Use an application specific user or something, but do not use the sa account under any circumstances.
This can be caused by any number of reasons, but the first thing to look at is the configuration and setup of the SQL Server itself.
Are named pipes enabled on the server? You can check this through the server configuration manager (on the SQL Server machine itself).
Is the user on the connection string (or the connection pool user if you are using SSPI) setup on the server?
Note:
I do hope the connection string you put up is an edited version of your real one, as there are a couple of issues with it:
Using the sa login - you should never do that as now any SQL exploit can do any damage it wants
Calling a sql server "webserver" - a really confusion naming decision
When it comes to connection strings, look at connectionstrings.com - they hold a good list of valid connection strings to many databases using different providers.
I got that error before...Make sure SQL server services are started
If that's not it, change the authentication mode to both server and windows.
It could be a connectionstring problem. Try comparing your connectionstring to the connectionstrings at http://www.connectionstrings.com but it could also be that the remote connection or the remote server (the webserver in this case) isn't allowed to connect to SQL.
Check if remote connections are allowed and named pipes and/or TCP/IP protocols are enabled on the database server.
But, based on the scenario you've described, I'd say it's the database-end that's refusing the connection (since you've already had a working solution).