Thanks Mike (again).
Working with Teradata's 3rd party ODBC drivers (DataDirect) has been
illuminating. Looks like, contrary to the Teradata documentation, that on
Linux via pyodbc they have wrapped the Windows version of their ODBC
driver. UID/PWD as well as Username/Password both work as long as you
specify the Driver parameter "Windows-style" where Driver={Teradata}. What
threw me off was that the "Driver" parameter per the Linux TD docs should
be the path to the tdata.so, which works in ODBC.INI but doesn't work from
a pyodbc.connect on Linux.
For the record, this works in pyodbc on Linux (although it shouldn't per
the docs as the string Teradata isn't defined in ODBC.ini or ODBCINST.INI):
conn =
pyodbc.connect('Driver={Teradata};DBCName=10.2.49.8;UID=testsqlatd;PWD=password')
In the ODBC.INI though on the same box it *must* be specified as or DNS
style connects from pyodbc will not work:
[td_testsqlatd]
*Driver=/opt/teradata/client/14.00/odbc_32/lib/tdata.so*
DBCName=10.2.49.8
Username=testsqlatd
Password=password
[default]
Driver=/opt/teradata/client/14.00/odbc_32/lib/tdata.so
Oddly this *doesn't* work on Linux although it mimics the working ODBC.INI:
conn = pyodbc.connect('Driver=
/opt/teradata/client/14.00/odbc_32/lib/tdata.so
;DBCName=10.2.49.8;UID=testsqlatd;PWD=password')
Error: ('IM002', '[IM002] [DataDirect][ODBC lib] Data source name not found
and no default driver specified (0) (SQLDriverConnect)')
Mystery solved for now. Thanks again.
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 sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
