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: DBD::Informix: 2003.04 DBI: 1.43 Perl: 5.6.1 (This is the one from the Sun Freeware site for Solaris 7.) Thanks for the quick response. -Will -----Original Message----- From: Jonathan Leffler [mailto:[EMAIL PROTECTED] Sent: Friday 10 September 2004 00:47 To: Rutherdale, Will Cc: [EMAIL PROTECTED]; 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: case SQLFLOAT: { $ double d; EXEC SQL GET DESCRIPTOR :nm_obind VALUE :index :d = DATA; sprintf(coldata, "%g", d); result = coldata; length = strlen(result); } break; 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 printf() directly. 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.
