[egenix-users] way to prevent floats from truncating to ints?

[Nathan Gossett]

Although we were never able to get the latest ODBC drivers to install 
correctly, we did manage to work around the issue by changing the 
offending column from a FLOAT to a NUMBER(10,2) type, which is correctly 
passed along without truncation even with the older driver.  This might 
not be a total solution to the issue, but it will work for our purposes 
and I thought I'd pass it along for future reference.

M.-A. Lemburg wrote:
> On 2008-04-09 22:26, Nathan Gossett wrote:
>> I'm using mxODBC to work with an Oracle 9 database, and when I try to 
>> fetch FLOAT data, they are being returned as ints.  Basically, I'm 
>> having the same issue as problem two in this posting:
>>
>> http://www.egenix.com/mailman-archives/egenix-users/2003-June/113452.html
>>
>> Setting the "leave scale 0 floats untouched" option is not really a 
>> solution, because then all of the NUMBER(10,0) data is returned as 
>> floats (which causes problems since they are supposed to be integers). 
>> I realize that mxODBC is acting exactly as documented, but I need 
>> floats to be returned as floating point numbers, while integers are 
>> returned as integers.  Is there some way around this?
> 
> What you are seeing is caused by a bug in the Oracle ODBC driver
> you are using: it returns a scale 0 value for regular floating
> values instead of the true value. As a result the mxODBC Zope DA
> then assumes that the scale of the float value is indeed 0 and
> thus an integer and truncates the values depending on the setting
> of the connection option.
> 
> There are ways to work around this problem by fetching all numbers
> as floats and then applying the conversion from floats to integers
> where necessary "by hand", but this is not ideal.
> 
> Please first try with the latest Oracle ODBC driver from the
> Oracle Full Client (not the Oracle Instance Client), apply
> all available patches and let us know whether the problem still
> persists with that driver version.
> 
> If that doesn't help either, we'll have to add a work-around to the
> underlying mxODBC Python interface and include that in the next version
> of the mxODBC Zope DA.
> 
> Thanks,