On 29 Gen, 21:03, Rick Morrison rickmorri...@gmail.com wrote:
I then added a wait option which simply sleeps for brief period after
closing the SA connections, and then does the connection count check. With a
1/2 second delay between the closing of the SA connection pool and the check
for
I worked up a test case that simulates your usage, and checks the number of
open MSSQL connections using a call to the system stored proc sp_who, so
it can run in a more automated fashion.
I originally got mixed results on this, it would pass about 50% of the time
and fail about 50% of the time.
On 24 Gen, 23:31, Rick Morrison rickmorri...@gmail.com wrote:
Oh... i didn't explain myself... I mean that it's already empty at the
first cycle of the loop...
It would be normal to not enter the loop if you haven't yet opened any
connections, as connections are opened on demand. Make
On 23 Gen, 23:43, Rick Morrison rickmorri...@gmail.com wrote:
From your earlier post:
a_session.close()
sa_Session.close_all()
sa_engine.dispose()
del sa_engine
but it does not close the connection!
Here's Engine.dispose (line 1152, engine/base.py)
def
Hey, seems that you've got the problem. conn = self._pool.get( False )
is the problem
It raises an Empty error...:
It's supposed to; that's the exit condition for the while True loop. It
does make it at least once through the loop, though right? Enough to close
any connections you may
On 24 Gen, 21:27, Rick Morrison rickmorri...@gmail.com wrote:
Hey, seems that you've got the problem. conn = self._pool.get( False )
is the problem
It raises an Empty error...:
It's supposed to; that's the exit condition for the while True loop. It
does make it at least once
Oh... i didn't explain myself... I mean that it's already empty at the
first cycle of the loop...
It would be normal to not enter the loop if you haven't yet opened any
connections, as connections are opened on demand. Make sure your program
issues at least one query during this test. If you
On 21 Gen, 16:18, Michael Bayer mike...@zzzcomputing.com wrote:
On Jan 21, 2009, at 5:22 AM, Smoke wrote:
Hi,
I'm not a SQLAchemy expert ( just an average user... ). I have an
application that's causing me some problems... It's a monitoring
application that connects to a MS Sql
To make pyodbc close the connection is settine pyodbc.pooling = False.
Whoa, I didn't know pyodbc automatically used ODBC connection pooling. Seems
like we should be turning that off if the user is using SQLA pooling.
--~--~-~--~~~---~--~~
You received this
I believe this is a setting you establish when you create the DSN
yourself, no ?
On Jan 23, 2009, at 12:27 PM, Rick Morrison wrote:
To make pyodbc close the connection is settine pyodbc.pooling =
False.
Whoa, I didn't know pyodbc automatically used ODBC connection
pooling. Seems
Good question, I don't know the answer.
But even if it were a DSN option, it's likely to be an optional one. In the
absence of an explicit setting, shouldn't we default to having the setting
off, not on? It sounds as if the pyodbc default is 'on'.
I would argue for forcing it off anyway, even if
On 23 Gen, 19:21, Rick Morrison rickmorri...@gmail.com wrote:
Good question, I don't know the answer.
But even if it were a DSN option, it's likely to be an optional one. In the
absence of an explicit setting, shouldn't we default to having the setting
off, not on? It sounds as if the
his answer here:
http://groups.google.com/group/pyodbc/browse_thread/thread/320eab14f6f8830f
You say in that thread that you're already turning off the setting by
issuing:
import pyodbc
pyodbc.pooling = False
before you ever open an SQLAlchemy connection.
Is that still the case?
pyodbc has the pooling implemented in Python ??? that seems weird ?
On Jan 23, 2009, at 2:46 PM, Rick Morrison wrote:
his answer here:
http://groups.google.com/group/pyodbc/browse_thread/thread/320eab14f6f8830f
You say in that thread that you're already turning off the setting
by
On Fri, Jan 23, 2009 at 3:05 PM, Michael Bayer mike...@zzzcomputing.comwrote:
pyodbc has the pooling implemented in Python ??? that seems weird ?
How did you get that idea from this thread? My read on it is that it uses
ODBC connection pooling.
OK, it should use whatever is set on the ODBC DSN then. im not sure
that pyodbc should have an opinion about it. is there a way to set
pyodbc.pooling = None or some equivalent ?
fyi I have MS SQL 2008 installed on a VM finally so i will be kicking
MS's ass for the new 0.6 refactor.
On 23 Gen, 20:46, Rick Morrison rickmorri...@gmail.com wrote:
his answer here:
http://groups.google.com/group/pyodbc/browse_thread/thread/320eab14f6...
You say in that thread that you're already turning off the setting by
issuing:
import pyodbc
pyodbc.pooling = False
before
OK, it should use whatever is set on the ODBC DSN then. im not sure that
pyodbc should have an opinion about it.
Eh?
is there a way to set pyodbc.pooling = None or some equivalent ?
It's pyodbc.pooling = False, as appears many times upthread
From the OP's description, it sounds like
On 23 Gen, 21:24, Rick Morrison rickmorri...@gmail.com wrote:
OK, it should use whatever is set on the ODBC DSN then. im not sure that
pyodbc should have an opinion about it.
Eh?
is there a way to set pyodbc.pooling = None or some equivalent ?
It's pyodbc.pooling = False, as
From your earlier post:
a_session.close()
sa_Session.close_all()
sa_engine.dispose()
del sa_engine
but it does not close the connection!
Here's Engine.dispose (line 1152, engine/base.py)
def dispose(self):
self.pool.dispose()
self.pool = self.pool.recreate()
On Jan 21, 2009, at 5:22 AM, Smoke wrote:
Hi,
I'm not a SQLAchemy expert ( just an average user... ). I have an
application that's causing me some problems... It's a monitoring
application that connects to a MS Sql Server, so it's always on.
Sometimes happens that casualy I have a
21 matches
Mail list logo
