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

Reply via email to