On 29 Gen, 21:03, Rick Morrison 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 "all connections
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 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 sure your program
> 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 a
On 24 Gen, 21:27, Rick Morrison 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 through the loop, t
>
>
> 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
On 23 Gen, 23:43, Rick Morrison 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 dispose(self)
>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.recre
On 23 Gen, 21:24, Rick Morrison 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 appears many times
>
> 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
On 23 Gen, 20:46, Rick Morrison 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 you ever ope
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.0.5
On Fri, Jan 23, 2009 at 3:05 PM, Michael Bayer wrote:
> 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.
--~--~-~--~~~---~--~~
You received thi
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
> b
>
> > 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?
On 23 Gen, 19:21, Rick Morrison 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 pyodbc default is 'on'
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
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. Seem
>
> > 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
On 21 Gen, 16:18, Michael Bayer 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 Server, so it's alway
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