I owe you a great big Thank-you, Jonathan. I succeeded in applying the patches you described. They worked beautifully.
-Will BTW I've noticed a couple of problems with installation in my local environment here. If I confirm them, how soon should I try to send the email before the next release? -----Original Message----- From: Jonathan Leffler [mailto:[EMAIL PROTECTED] Sent: Friday 10 September 2004 17:01 To: Jonathan Leffler Cc: [EMAIL PROTECTED]; Will Rutherdale Subject: Re: Losing Precision from FLOAT in DBD::Informix I've confirmed the problem - it appears in DBD::Informix 2003.04 on Solaris 8 with Perl 5.8.5, DBI 1.43, CSDK 2.90.UC1B4 (a beta release) running against IDS 9.50.UC1N395 (a nightly build); I have no doubt that the versions of Perl, DBI and o/s are immaterial. The versions of CSDK and IDS are also not dreadfully important either. The outline solution from last night is more or less correct - the formatting leaves something to be desired (as it drops even more digits than the current buggy solution). I hope to release the 'official' solution soon (though CSDK 2.90 will screw up a separate part of the build process once released on the general public, so I have a bit of work to do to clean up around that). In the mean time, these changes fix the trouble. At the top of the file: #include <float.h> In dbd_ix_st_fetch(): case SQLFLOAT: { $ double dblval; EXEC SQL GET DESCRIPTOR :nm_obind VALUE :index :dblval = DATA; sprintf(coldata, "%.*g", DBL_DIG, dblval); result = coldata; length = strlen(result); } break; case SQLSMFLOAT: { $ float fltval; EXEC SQL GET DESCRIPTOR :nm_obind VALUE :index :fltval = DATA; sprintf(coldata, "%.*g", FLT_DIG, fltval); result = coldata; length = strlen(result); } break; I don't like the repetition of 'result=coldata;length=strlen(result);' but I haven't spent the energy removing that yet. The '$' notation is a shorthand in Informix ESQL/C. The final fix will move those declarations up with the other variables between the EXEC SQL BEGIN DECLARE SECTION and EXEC SQL END DECLARE SECTION, which makes the '{}' lines unnecessary. - - - - - - - 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.
