Martin, Thanks a lot for the detailed explanation and prompt action. I will try out the new build.
LJ Yang -----Original Message----- From: Martin J. Evans [mailto:martin.ev...@easysoft.com] Sent: Tuesday, November 22, 2011 1:02 PM To: dbi-users@perl.org Cc: Yang, Longjiang Subject: Re: Teradata using DBD::ODBC On 22/11/2011 18:57, Martin J. Evans wrote: > On 22/11/2011 08:48, Martin J. Evans wrote: >> On 21/11/11 18:51, Yang, Longjiang wrote: >>> Hi, >>> >>> >>> >>> I use DBD::ODBC to connect to Teradata. I need to get column data type >>> back. when using $sth->{TYPE}. I got IDs not in $dbh->type_info_all. It >>> appears to happen to only CHAR and VARCHAR types. Does anyone know how >>> to get the data type information for a column (in a query)? Thanks. >>> >>> >>> >>> Here is the code. Note that -8 in $sth->{TYPE} is not defined in >>> $dbh->type_info_all. It is the ID for both CHAR and VARCHAR columns >>> defined in the table. I tried the same using DBD::ADO and got similar >>> issue. >>> >> >> type_info_all calls ODBC's SQLGetTypeInfo and the ODBC driver returns >> the result-set. {TYPE} returns the type returned from SQLDescribeCol. >> You are obviously on Windows where DBD::ODBC builds in Unicode mode >> by default. This causes DBD::ODBC to call SQLDescribeColW (the wide >> version of SQLDescribeCol) and in this case the driver will mostly >> return -8 (SQL_WCHAR) from char columns. However, DBD::ODBC does not >> yet call SQLGetTypeInfoW and hence the difference. Arguably, it is a >> bug in DBD::ODBC so by all means report it at rt.cpan.org and I will >> fix it as I am working in that area right now. >> >> <snipped test code> >> >> If you are in a position to rebuild a new DBD::ODBC and test the fix >> that will influence how quickly I get around to making the change. >> >> Martin > > In actual fact if you download DBD::ODBC 1.32_3 this version calls > SQLTablesW in a unicode build so you should try that. Get back to me > if you find any issues. > > Be aware I've not done column_info completely for Unicode yet (and the > other metadata methods like primary_keys) but I'm working on it right > now. > > Martin OOPs forget that - it was SQLGetTypeInfo not SQLTables. Sorry, I will work on SQLGetTypeInfo tonight. Martin
