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.
Lyle
