Re: RDBMS comparison tool

Lyle <[email protected]>
Newsgroups gmane.comp.lang.perl.modules.dbi.sybase.devel
Message-ID <[email protected]>
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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.