Re: RDBMS comparison tool

On 08/01/13 12:17, Lyle wrote:
> On 05/01/2013 20:49, Darren Duncan wrote:
>> On 2013.01.05 5:39 AM, Lyle wrote:
>>> I'm not overly familiar with Perl's internal handling of number. I guess if you
>>> have DECIMAL from a character string Perl will switch it out to an approximate
>>> the moment you do a calculation on it. Furthermore if the DBI (or the DBDs, I'm
>>> not sure where the distinction lies) is already putting it into a Perl decimal
>>> which is floating point, then the battle has already been lost before it gets to
>>> me.
>>
>> ...
>>
>> As for what DBDs actually do, well that's a different matter; but I'm talking about what *could* be done in the Perl somewhere, and typically I'd expect the DBD to make that decision on the Perl's behalf.
>
> The DBI docs have:
> "Most data is returned to the Perl script as strings. (Null values are returned as |undef|.) This allows arbitrary precision numeric data to be handled without loss of accuracy. Beware that Perl may not preserve the same accuracy when the string is used as a number."
>
> So as long as the DBD isn't breaking this, I should be getting decimal numbers back as strings.
>
>
> Lyle
>

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.

There are similar structures for GUIDs, dates, times and timestamps which DBD::ODBC also does not use as it would be responsible for any conversion.

More recently, DBD::ODBC binds integer columns as integers instead of strings as it is more efficient.

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.

I was unsure why you'd include SQL_ALL_TYPES in the table - it is not a type.

Martin
-- 
Martin J. Evans
Easysoft Limited
http://www.easysoft.com