Hi,
I'm trying to rewrite an application using Turbogears 2.x framework.
There is a query in that application, which works fine on ms-sql server:
here is the query:
-
select
Firma_ID = Firma.ID,
Firma_Kod = Firma.Kod,
Firma_Ad = Firma.Unvan,
Nakliye_Tutar =
running on fedora 13. yum installed everything.
got unixodbc installed and working, this includes iodbctest, isql,
tsql, and the following works:
import pyodbc
cnxn = pyodbc.connect(DSN=Default;UID=user;PWD=passw)
cursor = cnxn.cursor()
cursor.execute(use database)
cursor.execute(select * from
On Dec 23, 2010, at 1:31 PM, Pirate Fibonacci wrote:
running on fedora 13. yum installed everything.
got unixodbc installed and working, this includes iodbctest, isql,
tsql, and the following works:
import pyodbc
cnxn = pyodbc.connect(DSN=Default;UID=user;PWD=passw)
cursor =
Hello everyone!
I am currently working with a webserver (Grok) that starts different
threads (automatically) for the requests that arrive to it.
The information is serialized in a MySQL database (which is acceded
through SqlAlchemy). The users' information is stored in that MySQL
database. The
On Dec 23, 11:42 am, Michael Bayer mike...@zzzcomputing.com wrote:
If you want to see exactly what gets passed:
python from sqlalchemy.engine.url import make_url
from sqlalchemy.connectors import pyodbc
pyodbc.PyODBCConnector().create_connect_args(make_url(mssql+pyodbc://Defau
lt))
On Dec 23, 2010, at 2:16 PM, Pirate Fibonacci wrote:
On Dec 23, 11:42 am, Michael Bayer mike...@zzzcomputing.com wrote:
If you want to see exactly what gets passed:
python from sqlalchemy.engine.url import make_url
from sqlalchemy.connectors import pyodbc
On Dec 23, 2010, at 2:09 PM, Hector Blanco wrote:
Hello everyone!
I am currently working with a webserver (Grok) that starts different
threads (automatically) for the requests that arrive to it.
The information is serialized in a MySQL database (which is acceded
through SqlAlchemy). The
Thank you for your quick reply!
I tried to change the method that grabs the user to:
def getByName(userName):
retval = None
try:
retval = Database.session.query(User.User).filter(
User.User.userName== userName
it only has to do with what your appserver does when a connection is broken.
The finally method is probably never called.You can change the Python
warnings filter to emit those warnings as exceptions, in which you should be
able to get stack traces in your logs.
On Dec 23, 2010, at
I seen that, pasting the 5th example in to the function shows the same
bug.. the allowed option of /db makes the driver become null for some
reason. should I open a bug on sqlalchemy trac?
pyodbc.PyODBCConnector().create_connect_args(make_url(mssql+pyodbc://user:p...@host:123/db))
Ok! I'll let you know...
Thank you so much!
It seems to fail less with the finally, though :)
2010/12/23 Michael Bayer mike...@zzzcomputing.com:
it only has to do with what your appserver does when a connection is broken.
The finally method is probably never called. You can change the
its filled in by the MSSQL dialect under normal circumstances.
On Dec 23, 2010, at 4:34 PM, Pirate Fibonacci wrote:
I seen that, pasting the 5th example in to the function shows the same
bug.. the allowed option of /db makes the driver become null for some
reason. should I open a bug on
With that (catching all the errors) seems to work better.
It also seems that the problem improves if I wait a bit (4 or 5
seconds) after the server is started...
2010/12/23 Hector Blanco white.li...@gmail.com:
Ok! I'll let you know...
Thank you so much!
It seems to fail less with the
Hello
Is there a nice way to get the subquery object that relates to anon_1
in the below case so you can use it to filter on?
You can get it by q._joinpoint['_joinpoint_entity'] but that is
clearly private.
Thanks
David
class Employee(object):pass
class Manager(Employee):pass
class
On Dec 23, 2010, at 8:38 PM, kindly wrote:
Hello
Is there a nice way to get the subquery object that relates to anon_1
in the below case so you can use it to filter on?
You can get it by q._joinpoint['_joinpoint_entity'] but that is
clearly private.
Thanks
David
class
Oh I see.
The issue was that the query was trying to filter on the parent. i.e
query(ManagerInfo).join(manager).filter(Employee.foo == 'bar')
This makes a cross join.
The use case is that this point in the application the ManigerInfo did
not know what it had joined to. All it knew was that it
16 matches
Mail list logo
