I have a website hosted on GoDaddy server and many users access this website with their respective username and passwords. My database is in Azure. All of a sudden when the users of this website try to access the website with their username and password they fail to be identified as valid users though they are valid.
consequently when such a thing happens almost for more than 5 mins no user can login to the website. but i can very well connect to the database from my local server or through the azure portal.
the series of errors that gets logged into event viewer are as follows:
System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
System.Data.SqlClient.SqlException: a transport-level error has occured when sending the request to the server.(provider:TCP provider,error:0 - An existing connection was forcibly closed by the remote host.)
System.Data.SqlClient.SqlException: 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 - 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.)
SourceEdge.BCL.BCLException: Unable to Execute ---> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.
System.ArgumentNullException: Value cannot be null.
Parameter name: connection
after the error shown in 5 occurs all the subsequent logins will result in invalid user though the values are not null.
Can you tell me why this error happens all of a sudden. but it gets back to normal after a few minutes or even takes hours sometimes.
I'm not sure if you're aware of some pitfalls regarding connection handling to SQL Azure. The SQL Azure service might close connections at any time for some reasons. What you need is so called Transient condition handling. Not sure if this is the problem, but if you'are not aware of this, I'd suggest you read the following resources:
Microsoft Technet - Windows Azure SQL Database Connection Management
Microsoft Technet - Retry Logic for Transient Failures in Windows Azure SQL Database
Related
Am seeing an intermittent issue with a production SQL box, with errors returning:
System.Data.SqlClient.SqlException: 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: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
Running perfmon shows me that there are a maximum of 15 user connections open - on many occassions we open much more than this in the past. So i think this rules out connections that are left open.
Furthermore this is a production application that has not undergone changes over the past couple of months, and has always run perfectly well.
I am thinking maybe DNS issues, or siwtch issues possibly, as the web and SQL boxes are running on the same network, without firewalls in between.
Can anybody else shed any light.
One another note - the reference to "provider: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server" - i assume this denotes a connection via named pipes. I actually disabled named pipes earlier in an attempt to force TCP?
SQL Server Management Studio is not connecting on my database server machine at production server.
Whereas production sites accessing database. When I tried to connect database from SSMS, I get this error:
Cannot connect to 111.11.11.11.
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: Named
Pipes Provider, error: 40 - Could not open a connection to SQL Server)
(Microsoft SQL Server, Error: 53)
I was using this SSMS last couple of years,n this SSMS is running fine since more then year on production database server n i didn't closed ever, now when i connecting this SSMS but facing this issue, whereas my sites which accessing this database is working fine.
I also tried to access database from sqlcmd but no luck n facing facing this error:
HResult 0x35, Level 16, State 1
Named Pipes Provider: Could not open a connection to SQL Server [53].
Sqlcmd: Error: Microsoft SQL Server Native Client 10.0 : A network-related or instance-specific error has occurred while establishing a connection to SQL Server.
Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online..
I thinks we resolved the issues.
1. Active Directory server was not behaving, so
2. SQL server couldn't run without credentials and
3. they found another SQL server issue and fixed it.
We started looking into the SQL connections that my team had found and it lead us to find that the Active Directory server had basically crashed. It was allowing us to log in however it wasn't able to access the majority of the AD functionality. We ended up rebooting the AD server which corrected the issue however we were still seeing issues with the SQL cluster manager and SQL itself was rejecting connections on a somewhat regular basis.
After the AD server was rebooted we were able to log into the SQL cluster manager but with limited capabilities, since it had been erroring due to the AD issue we restarted the cluster service to see if this would correct the issue. This caused the SQL service to fail over to the passive server and caused SQL to start rejecting even more connections than it had been. The cluster service started working with this restart however the SQL connections were getting worse. We found that the IPv6 protocol was enabled for the SQL service which causes problems, like the ones we were seeing, in SQL clusters, to disable this we had to reboot the 2 SQL servers. We rebooted them one at a time and once they were back up everything was working properly.
We have an in-house developed VB.Net Windows Forms application that is losing users' individual connections to the SQL Server 2008 R2 database.
The bolded message below is what appears.
A transport-level error has occurred when sending the request to the server. (provider: TCP Provider, error: 0 - An existing connection was forcibly closed by the remote host.)
I have looked at many numerous articles both from Microsoft and others, but have been unable to pinpoint the issue.
Sometimes it occurs when the user has been away from the open application for a long-time; others maybe less than 20 minutes.
Any assistance would be appreciated.
This happens when the network connection is suddenly lost. It happens to me when I open my SQL Server and walk away for a long time and come back it happens.
There are a few things to consider, first check the Firewall of the server and create inbound and outbound rules for SQL server. Then if there are any antivirus in the system take a look into its behavior.
Up until last night, my site (hosted by DiscountASP.net) and the SQL Azure database that it connects to were running normally.
For some reason, during the night, the site went down with a named pipe error. Error 40.
Having prefixed the server name with "tcp:" in the connection string, the error is now:
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 - 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.)
So, just to be clear, the web.config file did not change at all between the time the website last worked and the item the named pipe error came up.
Now, the username, password and instance name are all correct since the site runs locally against the remote SQl Azure server perfectly.
I've checked the instance name and the SQl Azure access rules, ensuring that the web server's IP address is whitelisted.
Any ideas on whats wrong?
If I understand this right, your local website (on-premise) can connect to SQL Azure, but your website deployed in Azure can't?
Make sure your firewall rules has the "allow other windows azure services to access this server". Checking this option off basically prevents any azure-hosted application/service from connecting to your database.
I have a service that talks to local instance of SQL Server. I am getting an error
System.Data.SqlClient.SqlException:
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: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server)
This error happens intermittently. Since this is part of my continuous integration process its painful as I have to carry out whole build process again.
I would like to make this clear that I am not getting the issue every time its random in nature.
Please help me with this.
Have you tried toggling the various connection interfaces via the SQL Server Confoguration tool? I suspect you may be connecting via TCP/IP, which could be the subject of network issues elsewhere. Because you're local to the server, you could disable that interface and force the use of Shared Memory, which should help you troubleshoot the problem.
For more information on the connection types, see http://msdn.microsoft.com/en-us/library/ms187892.aspx