Devart Forums

dear support,

i have big problem:

the real value at the database is:

+--------------------+
| oxweight |
+--------------------+
| 31.650000000000002 |
+--------------------+

but dbforge shows me: 31.65

i want to see the "REAL" values...
how do i see them ???

next problem: why am i unable to change "precision" of a double field:



thank you,
micha

i have big problem:
the real value at the database is:
+--------------------+
| oxweight |
+--------------------+
| 31.650000000000002 |
+--------------------+
but dbforge shows me: 31.65
i want to see the "REAL" values...
how do i see them ???

Please note that a double-precision floating-point number is accurate to approximately 15 decimal places, whereas you have more than 15.

next problem: why am i unable to change "precision" of a double field:

We were able to reproduce this issue and will fix it in one of the next product builds.

dear alexa,

sorry, i don´t understand

Please note that a double-precision floating-point number is accurate to approximately 15 decimal places, whereas you have more than 15.

the point is: a tool, that is not able to show me the "exact data" that exists at the database, is useless to me. so please tell me, how do i configure dbforge to show me the same data i see at the database.

thank you,
micha

We will investigate this issue in more details when developing the next product versions.

dear alexa,

this is really important!!
please keep that in mind.
people who are working with a free program like phpmyadmin set other values than me!
THAT IS A NO GO!!!

THANK YOU
micha

Hello Micha,

Please note that DOUBLE supports 15 decimal places. However, internally, MySQL stores 17 signs following the comma. That's why you are seeing such result.

If you need all the 17 signs to be displayed, you can use CAST. For example:

SELECT CAST(my_column AS DECIMAL(20, 18)) FROM my_table

In this situation we recommend to replace the DOUBLE type with DECIMAL one.

For better clarity of the described above, let's consider the following script:

USE test;

DROP TABLE IF EXISTS double_test;
CREATE TABLE double_test (
double_column double DEFAULT NULL,
decimal_column decimal(20, 18) DEFAULT NULL
)
ENGINE = INNODB
CHARACTER SET utf8
COLLATE utf8_general_ci;

INSERT INTO double_test VALUES(31.6500000000002, 31.6500000000002); -- 15
INSERT INTO double_test VALUES(31.65000000000002, 31.65000000000002); -- 16
INSERT INTO double_test VALUES(31.650000000000002, 31.650000000000002); -- 17
INSERT INTO double_test VALUES(31.6500000000000002, 31.6500000000000002); -- 18

SELECT double_column, CAST(double_column AS decimal(20, 18)), decimal_column FROM double_test

dear alex,

so the mysql client itself has a bug?
the mysql client itself is showing me wrong data?
is it that, what you try to explain me here?
and all people who are using phpmyadmin see wrong data ?
they all should see 31.65 and dbforge is the only client, which is
showing correct infos - is that your statement ?

regards,
micha

According to the documentation http://dev.mysql.com/doc/refman/5.6/en/ ... rview.html there is no bug in the MySQL client and it displays 15 signs following the comma correctly ("A double-precision floating-point number is accurate to approximately 15 decimal places").

phpMyAdmin, seems to apply CAST to a string or to DECIMAL, therefore, 2 additional signs are displayed. DbForge can display these 2 signs if you use CAST or if you change the data type to DECIMAL.

dear alex,

i don´t want to talk about technical details.
if the mysql-client has no bug, as you confirmed, i see what i want to see:

31.650000000000002

if u use dbforge, i have to modify (cast) my query, to see the same like
the mysql client or like phpmyadmin - THAT´S STILL THE POINT!

i don´t want to change anything, i want to make the same query on both sides,
on both systems, on both clients...

AND OF COURSE i want to see the SAME RESULT.

you still force me to change anything at my query.
the point is and will ever be:

the mysql client AND php/websites show me diffrent things, as i see on dbforge,
THIS gets me in trouble because my people see different things, than ME!
is this really so hard to understand ??

you force me to change (CAST) my query!
you force me to change something, so that i see the same result,
as all other poeple see - HEY! COME ON!
this cannot be the way a mysql client (dbforge!) should WORK!

sorry!

Hello Micha,

Thank you for the detailed explanation.

We decided to make this change in one of the next builds of the product.

dear alexa,

do you have any news concerning this issue ?
sorry, but this is really important.

thank you

The issues you reported are fixed in a new product build that hasn't been released yet.

great to hear that, devart is really doing well in fixing things, that´s why i like the client so much, it makes sense to invest time into this and help making things better, thx!

We would like to let you know that the new build 6.0.568 of dbForge Studio for MySQL, where the issues you reported are fixed, has been released and is available for downloading
http://www.devart.com/dbforge/mysql/stu ... nload.html

Thank you for your help in improving dbForge Studio for MySQL.

I can confirm this,
Thanks a lot for this Bugfix!