I have a table with DATE column. All the dates are valid i.e. no 0000-00-00. But we were in fact using only the year part of these dates. I tried changing the type of this column to YEAR(4), I found following scenarios:
On my local system, MySQL version 5.5.37 via MySQL CLI, changing type retains the year.
On my local system, MySQL version 5.5.37 via Adminer, changing type retains the year.
Our internal DB server, MySQL version 5.0.46 via MySQL CLI, changing type retains the year.
Our internal DB server, MySQL version 5.0.46 via PhpMyAdmin, changing type retains the year.
Staging DB server, MySQL version 5.6.13 via PhpMyAdmin, dates in columns get converted to 0000.
Staging DB server, MySQL version 5.6.13 via MySQL CLI, dates in columns get converted to 0000.
What could cause these issues and how can I solve this? Currently we created a Rake task where we first create an additional column, copy existing column dates to new one, alter the column and copy just years back.
Edit: http://dev.mysql.com/doc/refman/5.6/en/upgrading-from-previous-series.html
Try this
ALTER TABLE `tablename`
CHANGE `columnName` `columnName` YEAR
This returns you 0000 in phpmyadmin. You should create a new column and rename it and then delete the old one.
The YEAR(2) data type has certain issues that you should consider before choosing to use it.
As of MySQL 5.6.6, YEAR(2) is deprecated.
YEAR(2) columns in existing tables are treated as before, but YEAR(2) in new or altered tables are converted to YEAR(4).
Read more here:
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-13.html
Related
I have just created a new MySQL in an AWS Ubuntu instance.
Then I have copied a table from another MySQL server to the new created database.
This is the structure from some fields from one of the tables:
My issue is that every time I try to enter a new record on the table, there is an error at field fecha_recepcion_disp:
I have checked if the original table from where I have copied the table has the same issue, but no, I am able to enter a new record without issues.
What should I check in the new database or table in order to avoid the issue?
EDIT:
The only difference between both servers is that the first one is located in the USA and the second one is located in France.
Issue solved:
The new server had value NO_ZERO_DATE in sql mode variable.
You're surely using different versions. MySQL 5.7+ stopped supporting zero values in the datetime field.
You can either use as default the current timestamp, or put null.
I'm trying to create a simple AWS Glue script that would load the data from one MySQL database to another.
I'm stuck at the beginning, because my source DB is configured to use "0000-00-00 00:00:00" as default values for timestamp columns.
I've tried using resolveChoice to convert the column to string, I've also tried (for a test) to only select columns that are not timestamp, but I always get the same error:
java.sql.SQLException: Value '0000-00-00' can not be represented as java.sql.Timestamp
I can't modify the DB to replace those values with NULLs and at this point I can't modify any part of Glue preferences (to include zeroDateTimeBehaviour in the jdbc string)
Upgrading to MySQL5.7 or later will solve this issue.
Changes in MySQL 5.7
I have a legacy application and am trying to move the MySQL server to a Unix based system (from windows).
My tables are stored as lowercase in MySQL but some of the queries from the application are “select * from UPPERCASE”. This gives me a table does not exist error. I’ve tried making lower_case_table_names=1 and that was not successful.
Is it possible to query with an UPPERCASE table name in MySQL 5.7?
I'm building a application that needs to store Timezones.
Rather than building my own table of timezones would it be copacetic to use mysql's already there table (mysql.time_zone_names)?
If I use a Time_zone_id of '94' and mysql updates its timezone tables, will 94 still be America/Chicago?
MySQL loads its timezone tables from your OS's /usr/share/lib/zoneinfo when you run mysql_tzinfo_to_sql. Then it keeps the data in the mysql database.
So the entries are only as stable as that file. If the OS adds or removes time zones in zoneinfo, and you reinstall your MySQL instance and run mysql_tzinfo_to_sql again to load the changed time zones, then the numeric time_zone_id values in MySQL could change.
I would recommend using the timezone name, not the numeric id.
I have a server in my company with mysql installed(on centos machine) in it. It already had data values inserted in it.
This morning when I tried to access my web application(which is connected by mysql) it gives me a database error.
Then I restarted mysql, I checked my database one table is automatically deleted and only 10 rows are inserted with all column value 1. In other table only one column is changed with same value on all row of that column.
I tried to run insert query but it shows timeout.And also phpmyadmin is slow.
I can guess that mysql is slow because mysql memory is full but why it deleted the row from one table and changed only one column of other table??
And is it possible to retreive my old database?
Any help would be apreciated.