It does sound like a leak of some kind, but this doesn't actually tell
us anything yet. pyodbc uses ODBC connection pooling by default,
which causes the driver manager to keep the connection alive for a
while.
The quickest way to test this is to turn off pooling in your test
program:
import pyodbc
pyodbc.pooling = False
n = pyodbc.connect('DRIVER={SQL
Server};SERVER=localhost;DATABASE=test_DB;UID=u;PWD=pass')
n.close()
del n
(The pooling variable is documented here:
http://code.google.com/p/pyodbc/wiki/Module)
Then test again. I think the connection will go away. If not, I'll
fix it immediately.
If it does go away, it just means we haven't found the cause of your
trouble yet.
Here's something I've done before: I created ConnectionWrapper and
StatementWrapper classes. I kept a class-level counter that I used as
a unique id, incremented in the constructor and logged in both the
constructor and destructor. (Don't decrement in the destructor or it
won't be unique.) To identify where you are in the code when you
create connections and/or statements you can also log a couple of
lines from the stack (using the traceback module) or you can trace out
the first 100 or so characters of the SQL. I then wrote a script to
see which connections weren't getting closed.
(Perhaps I should write a generic leak finder and keep it in a utils
directory.)
In the meantime, I'll perform some leak testing myself. There was a
leak in pyodbc about 3 years ago which caused serious problems for
me. I use it in 24x7 servers myself. (Windows services)