Skip to Content.
Sympa Menu

freetds - Re: [freetds] 20047: DBPROCESS is dead or not enabled

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: LacaK <lacak AT zoznam.sk>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] 20047: DBPROCESS is dead or not enabled
  • Date: Tue, 20 Sep 2016 07:10:47 +0200


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.

Thank you guys very much for replies.
I will try do it as you suggest ...
-Laco.




Archive powered by MHonArc 2.6.24.

Top of Page