Re: Pro*C: Loss of Decimal Places INSERTing From "double" Host Var into NUMBER(16,6) Column

"fitzjarrell_at_cox.net" <oratune_at_msn.com> wrote:

>Not without seeing the source code. You do realise that there is the
>BINARY_DOUBLE datatype available?

Sure, but I'm constrained to using the columns already in place, which are NUMBER(16,6). I myself think that the database is in some aspects not well-designed for its intended use. Nevertheless, the fact remains that (AFAICS) a (16,6) column ought to be able to store numbers like 1234567890.123456 without loss of precision.

Admittedly, that is 16 decimal digits, and IIRC, 16 digits is on the limit of what a C double type can represent, but that's not the problem here. We're not seeing loss of precision in the C domain; it's being lost somewhere between C/Pro*C and the database.

Here's the source code from my test program; there's not much to see!

    EXEC SQL BEGIN DECLARE SECTION;
    double TVTime=0.0;
    char TVSTime[20+1]="";
    EXEC SQL END DECLARE SECTION;     [ . . . init stuff, connect to database, etc. . . . ]

    EXEC SQL DELETE FROM TESTPRECISION;     EXEC SQL INSERT INTO TESTPRECISION (KEY,VALUE)

        VALUES
        (
        1,
        1234567890.123456 /* This works without truncating the data */
        );

    TVTime=(double)1234567890.123456;
    EXEC SQL INSERT INTO TESTPRECISION (KEY,VALUE)

        VALUES
        (
        2,
        :TVTime /* This gets truncated to 5 DP; appears as 1234567890.123460 
*/
        );

    sprintf(TVSTime,"%.6f",TVTime);
    EXEC SQL INSERT INTO TESTPRECISION (KEY,VALUE)

        VALUES
        (
        3,
        :TVSTime /* Inserting the value as a string works fine */
        );

Thanks again,

Martin Received on Thu May 22 2008 - 02:51:50 CDT