Pete
9/26/2002 6:07:00 PM
This tech note is in the release notes on the V3.0.2.4 driver:
-------------------------------------------------------------
Data Conversions
The Oracle ODBC Driver for Rdb follows the Microsoft ODBC 3.0 Software
Development Kit (SDK) guidelines for manipulating and displaying real
and double data types. Precision (the maximum number of digits used) of
SQL_DOUBLE and SQL_FLOAT data types is 15.
If double values are stored in a Oracle Rdb database precision for these
data types can be much greater than what ODBC currently supports. The end
result will be the loss of precision. For Example:
A float data type defined in Rdb with the
default precision contains a number such as:
123.9991029382123
When converted on the Windows platform the number
will drop precision to
123.99910293821
This loss of precision may have different behavior for different
applications. For Microsoft Access, the user is not allowed to update the
data. Microsoft Access thinks the data has changed, because Oracle Rdb
has the value 123.9991029382123 and Microsoft Access now has the
original but truncated number 123.99910293821. Microsoft Access cannot
update the row using the 123.99910293821 truncated number as a selection
criteria since that row does not exist in the Oracle Rdb database. Only the
original row with 123.9991029382123 exists in the Oracle Rdb database.
One workaround to the problem is to define the data type in Oracle Rdb as
BIGINT (13) or whatever is appropriate for your application. Microsoft
Access(R) will see BIGINT data types as text fields and allow you to
update the row without losing precision.
In Microsoft Query(R) the display will be incorrect. Lets take for example
the following double precision number to display:
-1.123400000000000E-001
with Microsoft Query the number is displayed as
-1.123400000000000E-00
Microsoft Query makes a call to SQLColAttributes returning the display size
of 22. The format defined in the ODBC SDK for display of a double precision
data is the following:
Total 22 Length
(a sign,15 digits,a decimal point,the letter E,a sign and
3 digits)
Our example contains a total string length of 23 with 16 digits
instead of the 15 digits for precision. This is why the data is displayed
wrong. One possible workaround to this problem may be to add a text field
that is computed by the cast of the double precision field within Oracle
Rdb. Then display the text field instead of the double.
$ SQL > alter table dbl_tab add dbltxt computed by cast
(dbl as char(23));
In general to avoid precision problems using ODBC, ensure that
data stored in the Oracle Rdb database for a double data type conform to the
specifications described in the Microsoft ODBC Programmer's Reference and
SDK Guide.
-------------------------------------------------------------
Any help?? What driver version are you using??
Pete
"Borje" <borje.johansson@bba-nonwovens.se> wrote in message
news:eowf6HbVCHA.2556@tkmsftngp11...
> I have a similar problem with Oracle Driver for RDB, when i try to INSERT
> data to RDB that is in a REAL format on RDB i get all kind of problems, it
> will not alow me to use any thing else then decimal or number and it will
> remove the decimals from the Insert no matter what i do, using Single or
> Double for input parameters wont go when RDB is having column as REAL....
>
> Regards
> BJ
>
> "Halvard Hagesæther" <halvard.hagesaether@accept.no> wrote in message
> news:6ed15aa.0207310430.14a8e3f3@posting.google.com...
> > Hi.
> >
> > I'm using an Oracle ODBC Driver for RDB as the driver for my
> > connection to our RDB-database. My problem is that not all data I get
> > from the database are correct.
> >
> > I do a simple "select * ..." and on some double values the precision
> > is not totally correct. I even use a strongly typed DataSet, so the
> > problem should not be that I use the wrong type. An example is:
> >
> > In database; 9,669999999999998
> > In DataSet; 9,669999999999988
> >
> > This leads to a concurrency violation when I'm updating :(
> >
> > Can anyone say anything about this? Is there another driver for rdb
> > that works better? I'm no expert on drivers and connections, but
> > everything with my connection works ... except for this problem.
> >
> > Thanks in advance,
> > Halvard.
>
>