DECLARE float_one, float_two, my_result NUMERIC(7,2)
my_result = CONVERT(float_one/float_two, DECIMAL(7,2));
In this mysql query, I do this type of operation in a stored procedure, but the Linux environment phpmyadmin throws the following warning:
Note: #1265 Data truncated for column 'float_one' at row 5
Does anyone have an idea how can I solve this problem?
CREATE TABLE IF NOT EXISTS `float_sample` (
`id` int(11) NOT NULL auto_increment,
`first_number` float(10,3) default NULL,
`second_number` float(10,3) default NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=3 ;
INSERT INTO `float_sample` (`id`, `first_number`, `second_number`)
VALUES (1, 2.900, 1.900), (2, 3.100, 22.100);
and the procedure
DELIMITER $$
DROP PROCEDURE IF EXISTS float_test$$
CREATE PROCEDURE float_test(IN my_ID INT)
BEGIN
DECLARE first_float, second_float DECIMAL(10,3);
DECLARE done INT DEFAULT 0;
DECLARE myCursor CURSOR FOR
SELECT `first_number`, `second_number`
FROM `float_sample`
WHERE `id` = my_ID;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
OPEN myCursor;
my_loop:LOOP
FETCH myCursor INTO first_float, second_float;
IF done = 1 THEN
LEAVE my_loop;
END IF;
END LOOP my_loop;
CLOSE myCursor;
-- SELECT first_float, second_float;
END;$$
DELIMITER ;
and the result
1 70 10:41:36 CALL mytests.float_test(1) 0 row(s) affected, 2 warning(s):
1265 Data truncated for column 'first_float' at row 2
1265 Data truncated for column 'second_float' at row 2 0.032 sec
Best Answer
What is the the value of float_one at the time of conversion ???
Note this example from MySQL 5.5.12 in Windows
It may be possible that data was truncated if a number bigger than 99999.99 was in float_one. Perhaps, mysql was converting float_one and float_two to DECIMAL(7,2) individually before performing division. Try using DECIMAL(10,2) or greater to accommodate large values.
UPDATE 2011-07-25 15:05 EDT
There are definite truncation problem going on here
According to MySQL Reference Manual Page 442 Paragraphs 2,3
You need to accommodate a larger precision and/or scale.
Here is an example as to why
I wrote this stored procedure using your specifications for DECMIAL and NUMERIC.
I used two values: 290.0 and 14.5 for this test.
Before calling the NumTest stored procedure, I manually calculated 290.0 / 14.5
I divided each number by 100, 10000, and 1000000 and tried again
So far, so good !!! Now for the stored procedure.
So my orignal two numbers work fine. Let's divide them by 100 and try again.
WAIT, we lost some precision. What happened ??? How did this happen ??? You need to accommodate more decmial digits (> 2)
UPDATE 2011-07-25 17:37 EDT
I substituted (7,2) with (10,7) in the stored procedure and got back the proper precision