Re: Teradata using DBD::ODBC
"Martin J. Evans" <[email protected]>
| Newsgroups | gmane.comp.lang.perl.modules.dbi.general |
|---|---|
| Message-ID | <[email protected]> |
On 22/11/2011 19:02, Martin J. Evans wrote:
> 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
DBD::ODBC 1.32_4 uploaded to pause which now calls SQLGetTypeInfoW.
Please test and report back here.
Martin