Looks like the *nix version of the ODBC driver I was using is simply
wrapping the Windows logic for parameters for DNS-less connections contrary
to the documentation
For the record in Teradata for DNS-based connections the ODBC connection
string would be on Linux:
'dsn=mydsn;Username=user;Password=pwd'
*BUT* for DNS-less connections the *nix version of the driver actually uses
this connection string:
'driver=Teradata;UID=user;PWD=pwd'
Possibly they re-used the parsing logic from the Windows driver? At any
rate, thanks for the information. That gave me the information I needed to
figure out what was going on.
On Saturday, January 10, 2015 at 12:25:37 PM UTC-8, Lycovian wrote:
>
> TL;DR:
> I'm trying to debug what is actually being sent to the pyodbc.connect
> function on connect in a custom dialect. I need to see the connection
> string that is being sent to the pyodbc.connect function *right* before
> it is sent but it has been difficult for me to unravel the layers of
> indirection on the create_engine call.
>
> Long version:
> If you care for more information I have this DSN related connect string
> for the custom dialect I am writing for Teradata:
> engine =
> sqlalchemy.create_engine("teradata://testsqlatd:password@td_testsqlatd",
> encoding='utf-8', echo=True)
>
> This connection string works and connects properly to my Teradata box
> (yay!).
>
> In my custom dialect I have subclassed so I can get some visibility into
> the ODBC connect string SQLA is constructing:
> def create_connect_args(self, url):
> connector = super(TeradataDialect_pyodbc,
> self).create_connect_args(url)
> print connector
> return connector
>
> This code appears to call sqlalchemy/connectors/pyodbc.py
> [create_connect_args]. And returns:
> [['dsn=td_testsqlatd;UID=testsqlatd;PWD=password'], {}]
>
> I assume that this string is roughly what is passed by SQLA to pyodbc at
> some future point as the ODBC connection string. In my case the string
> above connects successfully. Oddly enough though UID is not a valid ODBC
> connection parameter for the Teradata ODBC driver. For Teradata the
> parameter *must *be Username. Same with PWD, this isn't valid for the
> Teradata ODBC driver. It should be Password.
>
> According to my testing and the Teradata ODBC docs the valid version of
> this ODBC connection string should be:
> 'dsn=td_testsqlatd;Username=testsqlatd;Password=password'
>
> I have verified directly with pyodbc that the first form of the connect
> string fails and the version directly above works, yet somehow in
> SQLAlchemy it connects. Because of this I believe that SQLA is rewriting
> the string further before connecting to the Teradata ODBC driver via
> pyodbc. I can't find out where that is happening though. Because of
> this I would like to intercept the pyodbc.connect call and see exactly
> what ODBC connection string SQLA is invoking it with.
>
> Any ideas how to log what exactly the connection string that SQLAlchemy is
> sending to pyodbc.connect?
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
