On 08/01/13 16:58, Lyle wrote:
On 08/01/2013 13:19, Martin J. Evans wrote:
FYI
In ODBC a value may be bound as a numeric and the numeric returned is then a
structure:
typedef struct tagSQL_NUMERIC_STRUCT
{
SQLCHAR precision;
SQLSCHAR scale;
SQLCHAR sign; /* 1=pos 0=neg */
SQLCHAR val[SQL_MAX_NUMERIC_LEN];
} SQL_NUMERIC_STRUCT;
DBD::ODBC never actually binds numerics like this - it always binds as a string
and lets the driver do the conversion for it.
Good to know.
Also, be careful just saying this is what MS SQL Server does in your table -
your specific SQL Server returns those results, many will not. You obviously
have a fairly recent version as I can see sql_variant.
Good point, I was going to add this in my write up, but as I'm posting it here
I really should make it clear to everyone else.
Other drivers like DBD::Pg appear to return the same type list regardless of
version.
I was unsure why you'd include SQL_ALL_TYPES in the table - it is not a type.
It's just pull out the type list from DBI Constants:
http://search.cpan.org/~timb/DBI-1.623/DBI.pm#DBI_Constants
Your right, I should filter out SQL_ALL_TYPES.
So if I know understand correctly. DBI's type_info and type_info_all is an
emulation of SQLGetTypeInfo from ODBC, to describe to users what types should
be available for the database in question. It's not actually used internally?
Internally the DBD will decide how to map a columns reported type to Perl
types, be that integer or character.
Well I don't think I was around when type_info and type_info_all were added to DBI but I
believe it is based on ODBC's SQLGetTypeInfo. You might want to look at "Generating
the type_info" method in DBI::DBD. You need the ODBC driver for the database you
want to generate it for which is an even stronger suggestion it was based on ODBC.
Martin
--
Martin J. Evans
Easysoft Limited
http://www.easysoft.com
