On the upgrade to unixODBC 2.3.0 that sounds like your 2.2.11 is perhaps built 32bit and the 2.3.0 was built 64bit. Could that be the case?
I notice there is a v13 of the Teradata driver (at least for Windows). I've spoken to Nick (of unixODBC) and he said he has had some contact with Teradata in the recent past and they were certainly interested in getting it working with unixODBC.
The autocommit trace entry is interesting as it would normally be followed with a trace line at the same trace level showing the driver's DRIVER_ODBC_VER string. So it would seem we've probably narrowed the problem down to a hand full of lines in DBD::ODBC or SQLSetConnectAttr (for SQL_AUTOCOMMIT in the driver of unixODBC) or SQLGetInfo (for DRIVER_ODBC_VER in the driver or unixODBC). We could probably narrow it down more if you got a unixODBC trace.
To get unixODBC trace you need to locate your odbcinst.ini file (odbcinst -j will tell you if you installed odbcinst). Otherwise it is probably in /etc or /usr/local/etc. At the top of this file add the following lines:
[ODBC]
Trace = Yes
TraceFile = /tmp/unixodbc.log
then run the failing code once and post the last 50 or so lines from /tmp/unixodbc.log.
However, the most likely reason for the problem is you've built a rather old unixODBC 64bit and there is a conflict between what the driver and unixODBC/DBD::ODBC are using for SQLLEN and SQLULEN sizes. This is going to be difficult to ascertain unless you can contact Teradata.
Provide the log I've asked for but I strongly suggest you a) go to Teradata and ask which unixODBC you should be using with their driver or b) get 2.3.0 working because 2.2.11 is so old and pre dates SQLLEN/SQLULEN. |