RE: Losing Precision from FLOAT in DBD::Informix
From: Will Rutherdale (Will.Rutherdale_at_sciatl.com)
To: firstname.lastname@example.org Date: Fri, 10 Sep 2004 12:47:31 -0400
I didn't send version info initially because I hadn't yet escalated it to a
Problem Report. I was hoping you would point out something simple at the
user level I had overlooked.
I can get back to you with more info in a day or so, as well as trying some
of the ideas you suggested, but for now here's the basic version info:
Perl: 5.6.1 (This is the one from the Sun Freeware site for Solaris 7.)
Thanks for the quick response.
From: Jonathan Leffler [mailto:email@example.com]
Sent: Friday 10 September 2004 00:47
To: Rutherdale, Will
Cc: firstname.lastname@example.org; Reidy, Ron
Subject: Re: Losing Precision from FLOAT in DBD::Informix
An SQL FLOAT in Informix is equivalent to a C double. That means that the
loss of precision is not really excusable - and is not a problem in the
database. I'd virtually guarantee that (but virtual guarantees are only
ever worth the paper they are written on, of course :-)
So, the problem code, if it is still there, is likely to be in
dbd_ix_st_fetch() in dbdimp.ec.
For reasons that now elude me, 'case SQLFLOAT' fetches the value into a
'Decimal' - struct dec_t more usualy - so there is a chance that the problem
is in ESQL/C and the way it handles FLOAT to DECIMAL conversions -- this is
why the ESQL/C version is critical. If your version was old enough, I'd
state that the problem is most likely there with very little chance of being
wrong. The more recent the version, the less likely it is to be the
problem, but it still could be a problem. I'll try to reproduce the issue
tomorrow (other things being equal) - on Solaris 8.
The alternative way to work it is to modify the switch so that the SQLFLOAT
clause (and SQLSMFLOAT?) fetch into a native double variable, and then
format that into the coldata variable:
$ double d;
EXEC SQL GET DESCRIPTOR :nm_obind VALUE :index :d = DATA;
sprintf(coldata, "%g", d);
result = coldata;
length = strlen(result);
You may need to choose a different (more complex) format for the value than
just %g to get the full precision -- one of the reasons for not using
Let me know if any of this helps - and please do include the version
information next time! Thanks.
- - - - - - - Appended by Scientific-Atlanta, Inc. - - - - - - -
This e-mail and any attachments may contain information which is confidential, proprietary, privileged or otherwise protected by law. The information is solely intended for the named addressee (or a person responsible for delivering it to the addressee). If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate this message or any part of it. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete it from your computer.