Re: 20047: DBPROCESS is dead or not enabled
"James K. Lowden" <[email protected]> Mon, 19 Sep 2016 18:40:14 -0400
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 19 Sep 2016 14:44:32 +0200 LacaK <[email protected]> wrote: > I can not check status of connection before I send query? You cannot check the status of the connect before you send the query because the status changes only when the connection is used. Consider what it looks like at the TCP/IP level. The client went to sleep, and then woke up. Meanwhile, the server disconnected. From the client's perspective, nothing has changed: errno is still the same, the TCP/IP socket still appears valid. There's no syscall to test whether a socket is (still) connected to its peer. The only way to find out is to try to *do* something, which means reading or writing. Actually, the "went to sleep" part is unnecessary. How does one terminate a connection? By closing the socket, right? Does that cause a message to be sent to the peer, interrupting it, saying "the other party just closed the connection"? No. The peer learns of the disconnection when it next tries to read or write to its end. There's no inconsequential "are you there?" message in TDS, either. DB-Library can't send a message on your behalf to determine the connection status, because the state of the TDS session is under the application's control. So the only possible solution is to learn by doing: call the next db-lib function, get the error, and test it with dbdead(). It seems clunky, but it has the distinct advantage of not relying on Action at a Distance. Hope that clarifies things a bit. --jkl