Our application keeps on crashing once per day (at the start of the workday). Because of what it seems connection with database.
[31merror[39m: [SSL-QTEH-TD] E01000-SYSTEM_ERROR: [IBM][CLI Driver]
SQL30081N A communication error has been detected. Communication
protocol being used: "TCP/IP". Communication API being used:
"SOCKETS". Location where the error was detected: "000.00.00.00".
Communication function detecting the error: "recv". Protocol specific
error code(s): "104", "*", "0". SQLSTATE=08001
I'm unable to determine why this is happening.
You have a communication related SQL Error at the start of each working day. This implies that the network connectivity between your application and the database server was broken overnight, most likely for a scheduled downtime.
This could have been one or more of your app, the server your app runs on, any proxy or firewall servers servers between your app and the database server, the database, the server the database runs on.
Most likely it will be the database, allowing it to run reorgs and make backups. Next likely is a firewall, shutting down to allow maintenance. In any case your app needs to be able to detect the disconnect and recover.
Related
I have a client app using Entity Framework Core 5 with Npgsql to access PostgreSQL. The client app may make multiple connections to the database.
The problem is, after we killed the client app and shutdown the client machine, we can still see the connections from pgAdmin dashboard on the server.
We should not see these connection in pgAdmin as the client app is totally shutdown, does anyone know what is happening?
Is it because we kill the client app during a transaction or during a query wait?
If we inspect the connection query then we can see that it is performing a select statement. We suspect that it is waiting for another transaction to complete before returning the data but the client was killed and it didn't know about that. Would this be a right assumption?
I deployed my java web application on Bluemix Dedicated environment and use it with Cloudant Dedicated NoSql DB. In this DB i tried to return 60k documents and server returned
500 Error: Failed to establish a backside connection
to me. So i'm wondering about connection timeout in Bluemix, there're posts where people claim that Bluemix resets a network connection in 120 if there's no response received. Is it possible to change this setting, or maybe someone knows how to solve such problem.
P.S. When I deploy it on my computer then it works fine, but of course it takes some time. Particularly this case may be solved using cloudant pagination, but i develop service for scheduling REST-calls and if bluemix reset all connections after 2 minutes i'll have a big problems with it.
Not sure which Bluemix Dedicated you are using, but the timeout is typically global. Paging would work and I thinking a websocket based approach would work as well.
-r
We have moved our TFS data tier server to another machine. Everything was reconfigured and is working EXCEPT email alerts. Test emails are sent just fine. However, alerts are not happening. When I checked the event viewer, I'm seeing the following error:
ds:OLDSERVERINSTANCE db:Tfs_Configuration errors:-1 exception:System.Data.SqlClient.SqlException (0x80131904): 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: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified)
So, it appears that the email is still looking at the old database (which has been retired). Where/how can I change this?
In case anyone else runs into this scenario. The TFSJobAgent wasn't smart enough on reboot to recognize the data tier change. Doing the following worked:
1. Stop iis
2. Stop the TFSJobAgent
3. Start the TFSJobAgent
4. Start iis
Sessions are getting disconnected automatically (in the middle of working).
Disconnection happens for the users when they working by using telnet connection to Linux server via putty telnet application.
During the disconnection, the Network b/w utilization is high and no limitation for total number of users in a network.
Error "Hangup signal received (562)"
Any idea about this ??
The network connection was interrupted or a hangup signal was sent via "kill".
You mention network utilization being "high" when disconnects happen. How do you know that? What measurement are you looking at that tells you it is "high"? That might be a symptom of a networking issue that is at the root of the problem.
There are few directions:
OpenEdge has published this article with links to implementing keep-alive packets:
https://knowledgebase.progress.com/articles/Article/Telnet-connection-times-out-after-15-minutes
Increase the number of "instances" in xinetd.conf, and then restart the service.
Make sure that the database watchdog is up and running: https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/dmadm/prowdog-command.html
Check the database log file, to find out what happened just before the hangup (https://documentation.progress.com/output/ua/OpenEdge_latest/index.html#page/gsins/openedge-database-log-file.html)
A little background:
I have a Windows .NET application that is in use by approximately 40 field employees across North America. This program allows the users to enter data while in the field (away form internet access) and then synchronizes to our Sql Server 2005 database at night. A couple days ago, two of my users reported getting the following error when they performed an action that would attempt to connect to our server database (which uses .NET's SqlConnection class).
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)
Our field employees are typically operating on a hotel Wi-Fi connection, and at first I thought that they both coincidentally got on an "uncooperative" network the same day. The following day, having moved to different hotels, the problem went away for one of these users, but continued for the other.
Besides providing the error message, the purpose of this background is to point out that
this is the first time this issue has occurred in over a year of using this software, and
the majority of our users aren't having any problem connecting to our server database with the same software.
This makes me hesitate to think that the issue is at the server (most forums and blogs I've read on this error provide steps to ensure the SQL Server is configured properly).
Noticing the Named Pipes Provider portion of the error message, I guessed that maybe this user's computer or network was causing it to attempt connection via pipes rather than TCP, so I did try configuring the server to allow BOTH TCP/IP and Named Pipes for remote connections, where it was previously set to TCP/IP only. The error continued for this one user after changing this setting.
So now I'm left to brainstorm about what could be special about this one user's computer / software / internet connection that would hinder it from being able to connect to our SQL Server.
Our connection string does use our server's URL (not IP address), and I wondered if his laptop was having problems finding it by that address. However, he was able to access a website hosted from the same URL, so I guess the problem is somewhere else.
Any ideas would be greatly appreciated. Thanks!
You've probably long since solved this problem by now or moved on, but for those having similar problems with the Error 40/named pipes issue when connecting to a SQL server instance, the following simple solution worked for us:
You can force your client program to use TCP (or named pipes, or other available methods) by adding a prefix in your connection string.
For the .NET SQLConnection example, specify in the SQLConnection's connection string like so:
Server=tcp:192.168.0.1;Integrated Security=SSPI; database=sampledb
See this blog entry for more info.
Is it possible that they are being blocked by the hotel's firewall, which may only allow traffic on certain ports?