I noticed than MySQL throws an error if I try to add datetime with value less than 1970 year (for instance, 1969-01-01 00:00:01). The reason for this is that timestamp in MySQL starts only from 1970. But, in my testing server, I am able to add datetimes less than 1970. On production server - not. Why so? I suppose that MySQL was configured differently on production and testing servers using different sql modes. But I couldn't find which mode is responsible for such a behaviour.
You apparently have strict SQL mode enabled on the production server, but not the testing server. The documentation on Out-of-Range and Overflow Handling says:
When MySQL stores a value in a numeric column that is outside the
permissible range of the column data type, the result depends on the
SQL mode in effect at the time:
If strict SQL mode is enabled, MySQL rejects the out-of-range value
with an error, and the insert fails, in accordance with the SQL
standard.
If no restrictive modes are enabled, MySQL clips the value to the
appropriate endpoint of the column data type range and stores the
resulting value instead.
When I try to store that date into a TIMESTAMP column on a server without strict SQL mode, I get a warning:
Out of range value for column 'd2' at row 1
and it stores 0000-00-00 00:00:00 instead.
Related
I have mysql 5.6.27 installed on my two servers.
Database has a table which has a column type bigint(20) unsigned NOT NULL.
While inserting a string type value (like 1_2_3_4) in this column on one server it storing value 1 and showing a data truncation warning.
But if i am executing the same query on another server it showing the error message for data truncation and not letting the value inserted.
Just trying to understand why mysql is casting the value on one server but not on another.
Sounds like a configuration issue, specifically strict settings, see https://www.davidpashley.com/2009/02/15/silently-truncated/
I have 1 live database on a server (v5.5.58) and one local on my computer (v8.0.11) that is used as a testing database.
SELECT STR_TO_DATE("12:21:21", "%H:%i:%s")
Running this query on the server works fine while the same query locally returns date as null and a warning saying:
Warning: #1411 Incorrect datetime value: '12:21:21' for function str_to_date
I know that STR_TO_DATE works on MySql version 3.23 so it should work on version 8, right?
The ##SQL_MODE setting differs between your servers. Since 5.6, MySQL Server has used more strict default values for ##SQL_MODE.
If the NO_ZERO_DATE or NO_ZERO_IN_DATE SQL mode is enabled, zero dates or part of dates are disallowed. In that case, STR_TO_DATE() returns NULL and generates a warning
https://dev.mysql.com/doc/refman/8.0/en/date-and-time-functions.html#function_str-to-date
This same information appears in the documentation for previous versions.
You can often change newer servers to emulate the (usually permissive, sometimes wrong) behavior of older servers by changing the ##SQL_MODE to match, but do that with due discretion, since the more strict behavior is usually also more correct and helps avoid silent coercion of invalid values.
I've a table with a field DECIMAL(9,2) and I've 2 servers running both mysql 5.7
If I run this code
INSERT INTO `money_accounts` (`balance`) VALUES (9999999999.99);
On one of the servers it got inserted and value is truncated, on the other it raise a Out of range value for column balance error.
My question is, what is the configuration value that makes this happen? or why it's happening in one server and not in the other?
The definition
DECIMAL(9,2)
means 9 digits of total precision, with 2 digits after the decimal place. The value
9999999999.99
has 12 total digits of precision, with 2 after the decimal place. Hence, the value is out of range. Rightfully, MySQL should have thrown an out of range error in both cases. In the case where it "worked," my guess is that truncation occurred.
By the way, you should be using DECIMAL(12,2) or wider to store the value in your question.
Update:
One possible explanation for why one of your servers was doing the insertion while the other failed is that the first has traditional mode turned off. Run the following on both servers:
SELECT ##SESSION.sql_mode
If you see output looking like
STRICT_TRANS_TABLES, STRICT_ALL_TABLES, ...
then the server is running in traditional mode, which means it won't truncate but will reject. To turn it off, try running
SET SESSION sql_mode=''
and them the insert should succeed (with truncation). But in any case, you should not be relying on truncation in production. If you need more precision, then widen the column.
Reference: Automatically trimming length of string submitted to MySQL
If we read the documentation: http://dev.mysql.com/doc/refman/5.7/en/out-of-range-and-overflow.html
When MySQL stores a value in a numeric column that is outside the
permissible range of the column data type, the result depends on the
SQL mode in effect at the time
If strict SQL mode is enabled, MySQL rejects the out-of-range value
with an error, and the insert fails, in accordance with the SQL
standard.
If no restrictive modes are enabled, MySQL clips the value to the
appropriate endpoint of the range and stores the resulting value
instead.
So it means that You should set necessary sql mode that will not fail when out-of-range error happens.
There is no config parameter about that.
And resolution of same issue we can see here that says that disabling STRICT_TRANS_TABLES and STRICT_ALL_TABLES modes can fix Your problem.
I've got a table with a date-type field
browser transform: text/plain: dateformat
transform option: 0,'%d-%b-%Y','local'
When I execute my query it stores 01-Jan-1970 (default value) and on page it shows me 0000-00-00
What I want to do is to store in database and in page only the date and dateformat Y-m-d like 27.02.2016.
You've got a couple of things going on that I should address first.
The phpMyAdmin transform feature affects how you insert or view data from within phpMyAdmin only. It doesn't change how the data is stored internally with MySQL and it doesn't change how other applications interact with MySQL. So when you talk about displaying in your blog or storing in MySQL, those aren't affected by the transformations you've configured.
Next, you don't appear to be setting the post date, which means you're probably getting '0000-00-00 00:00:00' stored in the column. The exception would be if you allow NULL or set a default value. You can also get zeroes if you insert invalid dates.
The appropriate thing to is use the MySQL type and format the display on output -- either in SQL or in your application; I usually do it in my application. How to do that will depend on which programming language your application uses.
When inserting, you can use NOW() to insert the current time without having to compute it yourself.
I would like to store "2010-03-26 10:13:04 Etc/GMT" value in column of type datetime.
When I try to insert it I got exception:
SQLException: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '10:13:04 Etc/GMT', at line 1
How to insert data time with time zone.
you have to use datetime column, so value must be 2010-03-26 10:13:04 without any timezone steeings
Any string literal must be delimited with quotes
so, the query must be look like
INSERT INTO table set dtime='2010-03-26 10:13:04';
You can do that in a char field... but not in a datetime field. Look here for more information about timezones in mysql:
http://dev.mysql.com/doc/refman/5.1/en/time-zone-support.html
and for changing timezones in the database:
http://dev.mysql.com/doc/refman/5.1/en/time-zone-upgrades.html
MySQL's date/time formats don't support time zones. You would have to "normalize" the time to one specific time zone (usually UTC or the time zone the server is located in), or store the time zone in a different field and calculate the offsets by yourself.
Check out the alternative presented in this blog entry: Storing Times in mySQL it's a bit dated but I think what it says still applies. Apparently, Wordpress stores local and GMT times in two different DATETIME fields.
Related:
mySQL Server timezone support
Dealing with PHP server and MySQL server in different time zones