I restored a mysql database from a mysql server running on linux to one running on windows. Everything seemed fine until I tried to run an ALTER TABLE on one of the tables. The error I get if I try to ALTER anything is:
Error Code: 1067. Invalid default value for 'creation_date'
Now the strange thing is that dump file successfully restored and created the table. If I use Workbench to get the create statement for the table I see:
`creation_date` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
For the column which is causing an issue.
How can the CREATE TABLE statement succeed in such a way that I cannot perform alters on it now?
Some background on sql_mode and 'NO_ZERO_DATE': http://dev.mysql.com/doc/refman/5.1/en/sql-mode.html
You mentioned that you restored the tables from another server. If you used mysqldump then the answer to your question is that mysql turned off 'NO_ZERO_DATE' mode while loading the dumped SQL. Mysqldump (tested in 5.5) puts this line at the top of the dumped SQL:
/*!40101 SET #OLD_SQL_MODE=##SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
It also turns off foreign key checks and other useful things while loading the dump.
/*!40014 SET #OLD_UNIQUE_CHECKS=##UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET #OLD_FOREIGN_KEY_CHECKS=##FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
This explains why you were able to restore the tables, but when trying to alter you must play by stricter rules. If you really want to override this you can try the following just before your alter table:
mysql> SET SESSION sql_mode='';
Then alter table.
Related
im trying to upload my first wordpress website. Im using the local wordpress.org php my admin and the php my admin from 000webhost. Ive researched this a a lot here and changed all the settings people were saying from utf8mb4 to utf8 but it only caused more errors. I changed everything back to what it was (at least i think so and the error is the same as the beginning now). Anyone knows how i can get around this and import my db to 000.webhost with no errors? the Error is SQL query:
/*!40101 SET NAMES utf8mb4 */;
and
MySQL said: Documentation
1115 - Unknown character set: 'utf8mb4'
1) The first: If you can control ssh server. Please update mysql version. Your mysql too old. Maybe < 5.5.3.
2) The second: If you can't access ssh. Try to export your database with Mysql version 4.0.
With command line mysqldump --compatible=mysql40 -u user -p DB > dumpfile.sql
With web access phpmyadmin -> Select Database -> Export -> Custom - display all possible options -> Format-specific options ->
Database system or older MySQL server to maximize output compatibility with: Select MYSQL40.
Change content file .sql you exported
/*!50003 SET character_set_client = utf8mb4 */ ;
to utf8 only.
And replace by Ctrl H in Sublime change all from utf8mb4 => utf8
Hope this helps.
Just modify this into mysql Database.
wrong that modify ..... /*!40101 SET NAMES utf8mb4 /;
now corrected ..... /!40101 SET NAMES utf8 */;
just erase .... mb4 ....
its work now
I know this has similarities with the shroedingers table problem, but it reaches father than that.
I'm using Mysql Server 5.6 with innodb and file per table enabled.
I recently deleted a few databases from the mysql/server/data folder. They where too big and the server went away when I tried to do it with a drop, so I thought that was the cleanest option.
Now I'm trying to recreate the database from a sql-file and I get the messages "table xy already exists" for all the tables in the database, even though I checked the data folder and it was empty before I started the file. As the file is running, the idb files for the databases are created, not the frm though, so I end up with tablespaces that I cannot fill.
Obviously the server still has some information about the deleted databases saved somewhere that I need to get rid of, I just have no idea where to look for it.
Here an excerpt from the scheme file
-- MySQL dump 10.13 Distrib 5.6.13, for Linux (x86_64)
--
-- Host: localhost Database: test
-- ------------------------------------------------------
-- Server version 5.6.13-log
/*!40101 SET #OLD_CHARACTER_SET_CLIENT=##CHARACTER_SET_CLIENT */;
/*!40101 SET #OLD_CHARACTER_SET_RESULTS=##CHARACTER_SET_RESULTS */;
/*!40101 SET #OLD_COLLATION_CONNECTION=##COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET #OLD_TIME_ZONE=##TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET #OLD_UNIQUE_CHECKS=##UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET #OLD_FOREIGN_KEY_CHECKS=##FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET #OLD_SQL_MODE=##SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET #OLD_SQL_NOTES=##SQL_NOTES, SQL_NOTES=0 */;
--
-- Table structure for table `articles`
--
DROP TABLE IF EXISTS `articles`;
/*!40101 SET #saved_cs_client = ##character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `articles` (
`articlesID` int(5) NOT NULL DEFAULT '0',
PRIMARY KEY (`articlesID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = #saved_cs_client */;enter code here
The system structures in the file ibdata1 contain information about all InnoDB tables. It did not get cleaned up when you deleted the database directories.
Plan A: (This has some risk.) Dump the rest of your tables using mysqldump (or some other took); stop mysqld; delete ibdata1; restart mysqld; reload the dump.
Plan B: (Low risk.) Abandon those database names.
Plan C: (Serious risk.) Hire an expert (not me) to fiddle with ibdata1. (Suggestions: Percona, MariaDB, Oracle.)
Plan D: (unknown risk.) Do some web searches. Someone has probably conquered this problem.
It's a bad practice to delete file/s directly inside the data folder. Keep in mind that file/s has logs. Here's my suggestion:
Undo or Restore from the Recycle Bin the deleted files from the data folder
Make sure you are in the same server where you deleted them (ib_logfile, ibdata, etc should be there)
Try to DROP the table again
Please tell me if these thing works.
Im getting an error
SQL query:
-- --------------------------------------------------------
--
-- Table structure for table `wp_commentmeta`
--
DROP TABLE IF EXISTS `wp_commentmeta`;
MySQL said: Documentation
#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '-------------------------------------------------------
--
-- Table structure f' at line 1
This seems to happen on random tables. I remove the preceding mysql block and it will continue a few more tables before stopping with a similar error. I think it might be something to do with basic syntax.
Using phpmyadmin to import. And the original database is running MYSQL 5.5.42-37.1-log
The new database is running MYSQL 10.0.20-MariaDB
On the export screen on the original database phpmyadmin I clicked Custom - display all possible options and under Format-specific options: I unticked Display comments (includes info such as export timestamp, PHP version, and server version)
This removed all comments from the sql dump. I also had to remove the following lines from the top of the file.
/*!40101 SET #OLD_CHARACTER_SET_CLIENT=##CHARACTER_SET_CLIENT */;
/*!40101 SET #OLD_CHARACTER_SET_RESULTS=##CHARACTER_SET_RESULTS */;
/*!40101 SET #OLD_COLLATION_CONNECTION=##COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
This solved all my problems and it imported correctly.
I'm having a kind of unusual problem. I have a server running many applications with mysql databases and daily scheduled tasks generating backups for every database individually, with the help of .bat files.
This was working correctly until few days ago, the bat for only one of the databases has been creating files with the size of 1kb when I know it should be over 10,000 kb. It's very weird to me since it suddenly began to do that, no changes have been made to the server or the database structure. What's more, the script I use for every database is the same, only the database name changes. Here's my script:
CD C:\Program Files\MySQL\MySQL Server 5.1\bin
set DATE=%date%
set DATE=%DATE:/=%
set DATE=%DATE: =%
set DATE=%DATE::=%
set DATE=%DATE:,=%
set FILE=C:\\Backups\\DataBaseName_%DATE%.sql
mysqldump -uroot -p1 --routines=TRUE -r %FILE% DataBaseName
I've checked the root privileges and they're fine, specially since, as I said, it works on all databases but one.
I hope someone can give me some guidance on this, I really need this .bat running as it should and I haven't found anything that helps me solve the problem on Google. Does anyone have a idea of what is going on?
Thanks beforehand!.
After hours of looking around I found a piece of code that helped me find the problem, which wasn´t the disk space since I have plenty of room left.
To answer the question, the 1kb file contained the following:
-- MySQL dump 10.13 Distrib 5.1.57, for Win32 (ia32)
--
-- Host: localhost Database: DatabaseName
-- ------------------------------------------------------
-- Server version 5.1.57-community
/*!40101 SET #OLD_CHARACTER_SET_CLIENT=##CHARACTER_SET_CLIENT */;
/*!40101 SET #OLD_CHARACTER_SET_RESULTS=##CHARACTER_SET_RESULTS */;
/*!40101 SET #OLD_COLLATION_CONNECTION=##COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
/*!40103 SET #OLD_TIME_ZONE=##TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!40014 SET #OLD_UNIQUE_CHECKS=##UNIQUE_CHECKS, UNIQUE_CHECKS=0 */;
/*!40014 SET #OLD_FOREIGN_KEY_CHECKS=##FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0 */;
/*!40101 SET #OLD_SQL_MODE=##SQL_MODE, SQL_MODE='NO_AUTO_VALUE_ON_ZERO' */;
/*!40111 SET #OLD_SQL_NOTES=##SQL_NOTES, SQL_NOTES=0 */;
Not helpful at all for me, so I used the code that's almost at the end of the discussion in this link: http://epochmod.com/forum/index.php?/topic/16939-my-auto-backup-sqls-are-empty/
With that I was able to keep the command window opened for a longer time and read the error it displayed. The problem at the end was some conflict between table(s), column(s), function(s) or definer/invoker in a view I had in the database and the privilege Lock Tables. Honestly, I don't understand what that means, but I needed to solve it quickly so I just deleted the view (thankfully, I had no real use to it).
I hope this can help someone else as well :)
I have MySQL database version 5.1.36, that came with WAMP installation. I used it for development purposes on Windows XP SP3, and it has some data in it, which is cyrillic, and the collation for all of those tables/columns is set to utf8_general_ci.
Now the time has come to move this database to pseudo-production environment, which is on Debian Lenny. Version of MySQL here is 5.0.51a.
I tried the following:
I exported the databse with data from phpmyadmin on Windows and saved the .sql file to be in UTF8.
Then, I transferred it through WinSCP (both with default and binary transfer settings) to Linux machine.
I created the database through command line: mysqladmin -u root -p create nbs
Finally, I tried to create tables and fill the data:
mysql -u root -p --default-character-set=utf8 nbs < NBS_utf8_1.sql
However, this is where I'm getting the error, like:
ERROR 1064 (42000) at line 1: 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 '
CREATE TABLE IF NOT EXISTS `history_members` (
`id` int(11) NOT NULL AUTO_' at line 1
Something is messed up with encoding, I suppose... but don't know how and where. I think I read in the similar question on SO that binary mode for text transfer will only change the line breaks CRLF to LF (don't know if this is correct...). What am I missing here?
Thanks.
For this particular case, the problem was solved with the following modifications:
1) I set initial collation while creating the target database to utf8_general_ci,
2) I transferred the file with text mode through WinSCP,
3) I added SET NAMES 'utf8' COLLATE 'utf8_general_ci'; to the top of sql dump.
Here is what I found using PhpMyAdmin for a rough SQL import using remote shell :
/*!40101 SET #OLD_CHARACTER_SET_CLIENT=##CHARACTER_SET_CLIENT */;
/*!40101 SET #OLD_CHARACTER_SET_RESULTS=##CHARACTER_SET_RESULTS */;
/*!40101 SET #OLD_COLLATION_CONNECTION=##COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;