Out of Range Error while inserting into a MySQL decimal column - mysql

I have this tabular structure:
I get an error when i try to insert a specific set of value, query with those values is as below:
For longitude with value -161.9722021 it is throwing me an error, values less than 100 value were successfully inserted.
I don't see the value being out of range, the value i am giving in the query is not a string and is a decimal value as specified. I have checked other similar questions on the internet, but they actually had a value out of range. I am still unable to figure out why I am getting this error.

decimal(10,8) means that you have ten digits, and eight of those are for the decimal part.
This leaves two digits only for the integer part.
And that is why "values less than 100 are successfully inserted" -- because their integer part only takes two digits.
Use either DECIMAL(11,8) (same precision) or DECIMAL(11,7) (same size).

Related

MYSQL inserting UNC time into a column, yet getting errors

I am trying to insert a UTC timestamp into a row in mysql by using MySQLWorkBench. I have set the column type as TIMESTAMP, BIGINT, INT and TIME. No matter what I set it as I receive the same error - "incorrect (Type Here) value".
I am using this code to test this:
INSERT INTO mytablenamehere (`Time`) VALUES ('UNIX_TIMESTAMP(NOW(3))')
Should add I am on MYSQL 8.0. What am I doing wrong?
You're trying to insert a string. Your query should be VALUES (UNIX_TIMESTAMP(NOW(3))) (without the single quotes). Also note that (from the docs):
The return value is an integer if no argument is given or the argument does not include a fractional seconds part, or DECIMAL if an argument is given that includes a fractional seconds part.
So your column must be either an INT or a DOUBLE, depending on the precision you want.

Numeric value out of range for decimal data type?

I have a column called closing_price which is DECIMAL(6,2). My understanding is that this means it can take 6 digits and 2 decimal places, so the largest number that could fit in this column would be 999999.99.
However, I am getting this error now:
Numeric value out of range: 1264 Out of range value for column 'closing_price' at row 1 (SQL: insert into `stock_history` (`date`, `closing_price`, `stock_id`, `updated_at`, `created_at`) values (2000-02-01, 51900.000000, 214, 2020-02-07 09:51:03, 2020-02-07 09:51:03))
I don't understand how this could fall out of range of DECIMAL(6,2). Please correct me if my understanding is wrong, or help me troubleshoot this if I am right.
I don't know why the number 51900 is showing zeros for 6 decimal places. I am getting these values from an API and a lot of them have up to 6 zeros at the end, but this is the first one that threw and error after over a million inserts.
Your understanding is slightly off. DECIMAL(6,2) means that there are 6 total places of precision, with two of those places occurring after the decimal point. So, to store a value as large as 999999.99, you would actually need DECIMAL(8,2).
If you want a generally good type for storing currency values, you might follow the advice of this canonical SO answer, which suggests using DECIMAL(15,2).

What is the correct default value for a MySQL decimal field?

I have a decimal field in my MySQL database. I have defined it as this:
decimal(1,1) UNSIGNED NULL. But I would like to set a default value for it like 7.0, and this is the problem I have. Whenever I want to set this value, I get this error:
Invalid default value ...
I also tried to set it as 7,0 and 7 but it resulted the same error. What is the correct default value for a MySQL decimal field?
Note: I am using Navicat for MySQL
In MySQL, when declaring DECIMAL(P,S) :
The precision (P) represents the number of significant digits that are stored for values, and the scale (S) represents the number of digits that can be stored following the decimal point.
So in your example, DECIMAL(1,1) means at most 1 digit, and at most 1 digit after the dot... which doesn't really make sense.
To better understand, here are more examples:
DECIMAL(5,2): 5 digits, two of them being used for the fractional part. Hence, possible values range from -999.99 to 999.99
DECIMAL(5,0): no fractional part allowed, so it is equivalent to an integer with maximum 5 digits.
With UNSIGNED, the behavior is the same, but using a minus sign will throw an error.

Decimal datatype is rounding the values

I have set my MySQL field table data type to the decimal because from what I have read, I would be able to store the price with commas/dots in the decimal data type fields... The problem is that whenever I store any data with the comma or dot, MySQL is rounding it automatically up or down. Eg. When I'm executing the following query:
UPDATE table SET field = 114.21 WHERE id = 1;
Then field is set, but the value is rounded to 114, instead of displaying the data I set in the query (114.21) - is there any solution for that? Or I should just use other data type?
AFAIK the dot is the standard notation for decimal values. Using Commas may trigger SQL parse errors or may go unnoticed if the syntactical context allows for a comma to be there.
How did you define the precision of the DECIMAL column?
If it is DECIMAL(10, 2) it will have a total of 10 numbers of which 2 are decimal values (with 2 decimal rounding meaning that 10.215 is saved as 10.22 and 10.214 becomes 10.21).
If it is DECIMAL(10) it will not have any decimal values and be rounded to an integer.
If you use FLOAT or DOUBLE PRECISION you don't have to specify the number of decimal values but it has its own flaws.
As Mihai mentioned you need to define the proper precision for the decimal type, e.g. DECIMAL(10,2) for two decimal places.
When inserting a decimal value mySQL will round.
From the docs:
For inserts into a DECIMAL or integer column, the target is an exact data type, so rounding uses “round half away from zero,” regardless of whether the value to be inserted is exact or approximate.
See http://dev.mysql.com/doc/refman/5.0/en/precision-math-rounding.html for details.
Well before I have also an issue regarding on what to use on my numbers with decimal points. But problem solved by using DOUBLE(10,2) as my DATATYPE, and it shows the exact number on the database when you save it. Hope it will help.

mysql decimal rounding

I am inserting decimals into my MYSQL database but the values that end up in the DB are rounded, despite my having set the DB to DECIMAL(10,4). For example I set the discount to 6.5 and the DB records it as 7.
My query is:
$save = sprintf("
INSERT INTO discount
SET am_discount = %d,
tx_discount = '%s'
",
$_POST['am_discount'],
mysql_escape_string($_POST['tx_discount'])
);
I've tried setting the am_discount field to %u and %f as well, but it doesn't seem to make a difference.
As I mentioned, the am_discount field in my MYSQL DB is set to DECIMAL (10,4) and I've also tried (10,2) and (8,2).
What am I missing?
Try :
$save = sprintf("INSERT INTO discount SET am_discount = '".$_POST['am_discount']."',
tx_discount = '".mysql_escape_string($_POST['tx_discount'])."' ");
its seem to be database table column property issue, if some one can endorse me on it.
please change your table column property to "Float".
MySQL permits a nonstandard syntax: FLOAT(M,D) or REAL(M,D) or DOUBLE PRECISION(M,D). Here, “(M,D)” means than values can be stored with up to M digits in total, of which D digits may be after the decimal point. For example, a column defined as FLOAT(7,4) will look like -999.9999 when displayed. MySQL performs rounding when storing values, so if you insert 999.00009 into a FLOAT(7,4) column, the approximate result is 999.0001.
Reference :
http://dev.mysql.com/doc/refman/5.0/en/floating-point-types.html
It is not a database table column property issue. Decimal is the correct column type.
For inserts into a DECIMAL or integer column, the target is an exact data type, so rounding uses “round half away from zero,” regardless of whether the value to be inserted is exact or approximate.
See http://dev.mysql.com/doc/refman/5.0/en/precision-math-rounding.html for details.
This has nothing to do with the database, actually. It's sprintf behavior for %d.
%d The argument is treated as an integer and presented as a (signed) decimal number.