Patch works like a charm!
Thanks once again,
Alex
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group,
I had the following error since the update to SQLAlchemy 0.5.1 (we had
to upgrade because it fixed a bug we had in the previous version :P).
I'm not really sure how it manifest itself but here is the traceback:
Traceback (most recent call last):
[...]
File string, line 4, in __init__
File
Thank you for the reply.
However, this solution (though I'm ready to use it) would create a lot
of SQL queries comparing it with simple INSERT ... ON DUPLICATE KEY
UPDATE.
On the other hand, I admit the INSERT ... IN DUPLICATE KEY UPDATE
might not be available in other DBs. I would like the
fixed in trunk, for 0.5.2.
On Jan 23, 2009, at 4:44 AM, Lawrence Oluyede wrote:
I had the following error since the update to SQLAlchemy 0.5.1 (we had
to upgrade because it fixed a bug we had in the previous version :P).
I'm not really sure how it manifest itself but here is the
Hi there,
I have a table tblPerson that has a m:n relation with a table tblFlag using an
association table tblCompany_has_Flag
now I would like to find all persons, that do not have assigned any of list of
flags.
what I have tried among other things is the following:
s =
On Fri, Jan 23, 2009 at 2:43 PM, Michael Bayer mike...@zzzcomputing.com wrote:
fixed in trunk, for 0.5.2.
Ok, thank you. Do you have an estimated date of release?
Thank you for the hard work!
--
Lawrence, http://oluyede.org - http://twitter.com/lawrenceoluyede
It is difficult to get a man
possibly today.
On Jan 23, 2009, at 8:52 AM, Lawrence Oluyede wrote:
On Fri, Jan 23, 2009 at 2:43 PM, Michael Bayer mike...@zzzcomputing.com
wrote:
fixed in trunk, for 0.5.2.
Ok, thank you. Do you have an estimated date of release?
Thank you for the hard work!
--
Lawrence,
On Fri, Jan 23, 2009 at 2:55 PM, Michael Bayer mike...@zzzcomputing.com wrote:
possibly today.
Awesome.
--
Lawrence, http://oluyede.org - http://twitter.com/lawrenceoluyede
It is difficult to get a man to understand
something when his salary depends on not
understanding it - Upton Sinclair
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
camlost wrote:
Thank you for the reply.
However, this solution (though I'm ready to use it) would create a lot
of SQL queries comparing it with simple INSERT ... ON DUPLICATE KEY
UPDATE.
On the other hand, I admit the INSERT ... IN DUPLICATE KEY UPDATE
might not be available in other DBs.
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
Greg wrote:
I think I found one that might help. Where can I upload this HTML file
it generated?
In case you don't get a better answer: open the file in your browser,
then cut paste the text the browser displays (or take a screenshot of
the browser window and upload that as a gif or jpg).
Uh, did you guys not see my last message in this thread?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from 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
It appears this doesn't currently work as expected (ver 0.5rc2, Python
2.5) when the tables are reflected (autoload = True).
I have two reflected (legacy) tables that define similar properties with
different names and different units (both are time, one is in seconds
the other in minutes).
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
Yeah, I can get it to you, but in the reply box I'm not seeing
anything here about attachments. There's just Send, Discard, Add Cc,
or Edit Subject. I am set up to use this group only through the
browser.
On Jan 23, 12:35 pm, Don Dwiggins d...@dondwiggins.net wrote:
Greg wrote:
I think I
Thanks, I'll try this out and let you know how it goes.
On Jan 23, 12:43 pm, Rick Morrison rickmorri...@gmail.com wrote:
Uh, did you guys not see my last message in this thread?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to 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?
On Jan 23, 2009, at 1:43 PM, Toby Bradshaw wrote:
But what happens (if you add a few prints and whatnot to illustrate)
is
that the property setter is never called either when objects are being
instanced from the database or when setting the property of an
existing
instance of B. Seems
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
The commit mentioned earlier fixed the issue. Thanks for all the help.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe
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()
I was debugging some stuff recently and noticed different behavior in
one of my applications than I was expecting.
The behavior is the undesirable execution of some sql. The sql is used
to populate the value of a column_property. The column_property has
been deferred, however, and the property
Ive made an adjustment in r5720 such that _expire_state() will exclude
unloaded, deferred attribute names from the list of attributes to
expire. So deferreds won't load in that specific case. Otherwise,
explicitly expiring the deferred attribute or expiring when the
deferred attribute
31 matches
Mail list logo
