Issue 66: No way to determine if a connection has been dropped
Status:  NoFix
Owner: ----
Closed:  Dec 2009
Reported by gbron...@gmail.com, Aug 13, 2009
What steps will reproduce the problem?
1. Open a connection to a DB that drops connections after a timeout
2. Wait.
3. Try to use the connection. There is nothing in the interface that 
allows you to determine if the connection is still open.

What is the expected output? What do you see instead?
I expect a value on the connection object 'closed' once the connection has 
been dropped.



What version of the product are you using? On what operating system?
Current -- 2.1.X


Aug 13, 2009
Project Member #1 mkleehammer
Unfortunately this is by design since ODBC is client/server.  Databases don't
typically notify the clients, so there is no way for pyodbc to know.

What database are you using?  If there is way to find out, it seems reasonable to add
a flag or method that checks.

You didn't mention your operating system.  If you are using ODBC on Windows, using
connection pooling usually fixes this since a lot of drivers will check under the covers.

If not, you'll need your manual connection pool to perform a quick test before
handing out the connection.  I know SQL Server has a very fast stored procedure the
driver uses under the covers (xp_reset I think).  I've done this with manual
connection pools on Linux.  (Also, if you are using PostgreSQL for a large
website/server, consider using pgbounce.  I've heard a lot of good things about it.)

Status: Investigating
Nov 11, 2009
#2 gbron...@gmail.com
To clarify: 

1) This is using a python client connecting to Netezza via the linux ODBC library;
client is running on linux.

So this is a bit bleeding edge.
Dec 31, 2009
Project Member #3 mkleehammer
I'm going to have to close this since it isn't actually a pyodbc issue.

I hate to do so without finding something helpful for you, but I haven't been able to.  Netezza isn't real 
forthcoming with their documentation.

I do recommend bringing it up in the discussion group, though.
Status: Invalid
Nov 21, 2010
Project Member #4 mkleehammer
(No comment was entered for this change.)
Status: NoFix