Hi Lycovian,
Can you share your dialect for Teradata using pyodbc? I'm very interested.
Best,
On Tuesday, January 13, 2015 at 8:34:33 AM UTC+8, Lycovian wrote:
>
> 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?
>>
>
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable
Example. See http://stackoverflow.com/help/mcve for a full description.
---
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 sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
