Skip Menu |

This queue is for tickets about the DBI CPAN distribution.

Report information
The Basics
Id: 83238
Status: open
Priority: 0/
Queue: DBI

People
Owner: Nobody in particular
Requestors: COSMICNET [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: (no value)
Fixed in: (no value)



Subject: SQL_ALL_TYPES and SQL_UNKNOWN_TYPE share the same type code number
Hi All, These two type constants sharing the same type code leads to incorrect results when one requests type info: C:\>perl -MData::Dumper -e "use 5.16.0; use DBI qw(:sql_types); say 'SQL_ALL_TYPES=' . SQL_ALL_TYPES; say 'SQL_UNKNOWN_TYPE=' . SQL_UNKNOWN_TYPE;" #SQL_ALL_TYPES=0 #SQL_UNKNOWN_TYPE=0 C:\>perl -MData::Dumper -e "use DBI qw(:sql_types); my $dbh = DBI->connect('DBI:mysql:database=test;host=localhost;','test','test'); print Dumper( $dbh->type_info( SQL_UNKNOWN_TYPE ) )" #returns all types C:\>perl -MData::Dumper -e "use DBI qw(:sql_types); my $dbh = DBI->connect('DBI:Pg:database=test;host=localhost;','test','test'); print Dumper( $dbh->type_info( SQL_UNKNOWN_TYPE ) )" #returns all types SQL_ALL_TYPES does appear in the standard. SQL_UNKNOWN_TYPE doesn't appear in the standard. Googling seems to suggest that SQL_UNKNOWN_TYPE is used by a number of DBMSs, with type code 0. I can't think of a solution other than to re-code SQL_UNKNOWN_TYPE to something within the DBI specific permissible range, such as 9000. But then that would probably break several DBDs. The DBI docs don't mention SQL_UNKNOWN_TYPE. So maybe the only workable solution is to add a caveat? Lyle
On Sat Feb 09 10:09:47 2013, COSMICNET wrote: Show quoted text
> Hi All, > These two type constants sharing the same type code leads to incorrect > results when one requests type info: > > C:\>perl -MData::Dumper -e "use 5.16.0; use DBI qw(:sql_types); say > 'SQL_ALL_TYPES=' . SQL_ALL_TYPES; say 'SQL_UNKNOWN_TYPE=' . > SQL_UNKNOWN_TYPE;" > > #SQL_ALL_TYPES=0 > #SQL_UNKNOWN_TYPE=0 > > C:\>perl -MData::Dumper -e "use DBI qw(:sql_types); my $dbh = > DBI->connect('DBI:mysql:database=test;host=localhost;','test','test'); > print Dumper( $dbh->type_info( SQL_UNKNOWN_TYPE ) )" > > #returns all types > > C:\>perl -MData::Dumper -e "use DBI qw(:sql_types); my $dbh = > DBI->connect('DBI:Pg:database=test;host=localhost;','test','test'); > print Dumper( $dbh->type_info( SQL_UNKNOWN_TYPE ) )" > > #returns all types > > SQL_ALL_TYPES does appear in the standard. > SQL_UNKNOWN_TYPE doesn't appear in the standard. > > Googling seems to suggest that SQL_UNKNOWN_TYPE is used by a number of > DBMSs, with type code 0. > > I can't think of a solution other than to re-code SQL_UNKNOWN_TYPE to > something within the DBI specific permissible range, such as 9000. But > then that would probably break several DBDs. > > The DBI docs don't mention SQL_UNKNOWN_TYPE. So maybe the only workable > solution is to add a caveat? > > > Lyle
I don't see at all why SQL_UNKNOWN_TYPE or SQL_ALL_TYPES should be renumbered just because they are the same. The type_info method in DBI I guess is based on ODBC's SQLGetTypeInfo and you are only supposed to pass certain types (and SQL_ALL_TYPES) to SQLGetTypeInfo (see http://msdn.microsoft.com/en-us/library/ms714632%28v=vs.85%29.aspx). SQL_UNKNOWN_TYPE is returned by SQLDescribeCol if the column type is unknown (see http://msdn.microsoft.com/en-us/library/ms716289%28v=vs.85%29.aspx). As far as I'm aware SQL_UNKNOWN_TYPE could just be removed from DBI's export list but it is far easier to just not use it. Martin -- Martin J. Evans Wetherby, UK