MySQL Import Issue - mysql

I am trying do export a database from one database to another. I am using the following commands to export and import:
export: mysqldump -u root -p dwad dwadallauth.sql
import: $ mysql -u root -p dwad < dwadallauth.sql
I then checked and it was evident the original database was created using:
CREATE DATABASE dwad CHARACTER SET utf8 COLLATE utf8_general_ci;
and then privileges were granted as follows:
GRANT ALL PRIVILEGES ON dwad.* TO 'dwad'#'localhost' IDENTIFIED BY '9LSo1SxqdJF45PL';
So I tried the following import:
import: $ mysql -u root -p --default-character-set=utf8 dwad < dwadallauth.sql
However, whenever I try to import I get the following error:
ERROR 1064 (42000) at line 54: 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 '(6) NOT NULL,
`sent` datetime(6) DEFAULT NULL,
`key` varchar(64) NOT NULL,
' at line 3
I have checked and the MySQL versions are as follows:
Export: mysql Ver 14.14 Distrib 5.7.13, for Linux (armv7l) using EditLine wrapper
Import: mysql Ver 14.14 Distrib 5.5.50, for debian-linux-gnu (x86_64) using readline 6.3
I hope someone may be able to point me in the right direction, many thanks in advance.
PS
Below is a copy of the SQL file created by the export:
-- MySQL dump 10.13 Distrib 5.7.13, for Linux (armv7l)
--
-- Host: localhost Database: dwad
-- ------------------------------------------------------
-- Server version 5.7.13-0ubuntu0.16.04.2
/*!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 `account_emailaddress`
--
DROP TABLE IF EXISTS `account_emailaddress`;
/*!40101 SET #saved_cs_client = ##character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `account_emailaddress` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`email` varchar(254) NOT NULL,
`verified` tinyint(1) NOT NULL,
`primary` tinyint(1) NOT NULL,
`user_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `email` (`email`),
KEY `account_emailaddress_user_id_2c513194_fk_auth_user_id` (`user_id`),
CONSTRAINT `account_emailaddress_user_id_2c513194_fk_auth_user_id` FOREIGN KEY (`user_id`) REFERENCES `auth_user` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = #saved_cs_client */;
--
-- Dumping data for table `account_emailaddress`
--
LOCK TABLES `account_emailaddress` WRITE;
/*!40000 ALTER TABLE `account_emailaddress` DISABLE KEYS */;
/*!40000 ALTER TABLE `account_emailaddress` ENABLE KEYS */;
UNLOCK TABLES;
--
-- Table structure for table `account_emailconfirmation`
--
DROP TABLE IF EXISTS `account_emailconfirmation`;
/*!40101 SET #saved_cs_client = ##character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `account_emailconfirmation` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`created` datetime(6) NOT NULL,
`sent` datetime(6) DEFAULT NULL,
`key` varchar(64) NOT NULL,
`email_address_id` int(11) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `key` (`key`),
KEY `account_ema_email_address_id_5b7f8c58_fk_account_emailaddress_id` (`email_address_id`),
CONSTRAINT `account_ema_email_address_id_5b7f8c58_fk_account_emailaddress_id` FOREIGN KEY (`email_address_id`) REFERENCES `account_emailaddress` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
/*!40101 SET character_set_client = #saved_cs_client */;

According to the manual for mysql 5.7:
Downgrading more than one release level is supported using the logical downgrade method, but only if you downgrade one release level at a time. For example, you can downgrade from 5.7 to 5.6, and then to 5.5.
You are trying to go from 5.7 to 5.5 in one step. This might be causing your problem.
See https://dev.mysql.com/doc/refman/5.7/en/downgrading.html

datetime(6) is not supported in older versions. You will have to lose the microseconds during the downgrade.

Related

Export MySQL Database from HeidiSQL to SQL Server. Problem with simple quotes

I have a remote MySQL DB in a hosting that I need to export to my local SQL Server.
I use Heidi SQL to connect the DB and I use the Export to single .sql file
The problem is that the DB is 5GB and the .sql file is 2.3GB. So I can't open the .sql with SSMS because it says that the file is to big.
So I try to run the command sqlcmd on console >sqlcmd -S localhost\SQLEXPRESS -i "C:\backup\file.sql"
but it fails because of the simple quotes:
-- --------------------------------------------------------
-- Host: IP
-- Versión del servidor: 5.5.60-0+deb7u1-log - (Debian)
-- SO del servidor: debian-linux-gnu
-- HeidiSQL Versión: 12.0.0.6468
-- --------------------------------------------------------
/*!40101 SET #OLD_CHARACTER_SET_CLIENT=##CHARACTER_SET_CLIENT */;
/*!40101 SET NAMES utf8 */;
/*!50503 SET NAMES utf8mb4 */;
/*!40103 SET #OLD_TIME_ZONE=##TIME_ZONE */;
/*!40103 SET TIME_ZONE='+00:00' */;
/*!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 */;
CREATE DATABASE IF NOT EXISTS `MyDB` /*!40100 DEFAULT CHARACTER SET utf8 */;
USE `MyDB`;
CREATE TABLE IF NOT EXISTS `Account` (
`id` char(36) NOT NULL,
`name` varchar(150) DEFAULT NULL,
`date` datetime DEFAULT NULL,
`created_by` char(36) DEFAULT NULL,
`description` text,
PRIMARY KEY (`id`)
)
It should not be this extrange quote (``) it should be normal quote (''). Is there a way to generate the .sql script from Heidi with normal quotes so I can execute it in the cmd?? I can't change manually with crt+f because I can't open the 2.3GB file
The SQL syntaxes differ between MySQL and SQL Server. When trying to use direct database dump, you will likely have other incompatibilities as well.
Try using the Microsoft SQL Server Migration Assistant for MySQL instead.

How to convert MySQL dump to SQL Server format

I have downloaded a SQL dump of wikimedia
It has below information
I do not want to install any MySQL server and just want to convert this code so that I can import to SQL Server 2019
-- MySQL dump 10.16 Distrib 10.1.38-MariaDB, for debian-linux-gnu (x86_64)
--
-- Host: 10.64.32.116 Database: enwiktionary
-- ------------------------------------------------------
-- Server version 10.1.43-MariaDB
/*!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 */;
/*!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 `category`
--
DROP TABLE IF EXISTS `category`;
/*!40101 SET #saved_cs_client = ##character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `category` (
`cat_id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`cat_title` varbinary(255) NOT NULL DEFAULT '',
`cat_pages` int(11) NOT NULL DEFAULT '0',
`cat_subcats` int(11) NOT NULL DEFAULT '0',
`cat_files` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`cat_id`),
UNIQUE KEY `cat_title` (`cat_title`),
KEY `cat_pages` (`cat_pages`)
) ENGINE=InnoDB AUTO_INCREMENT=50325885 DEFAULT CHARSET=binary ROW_FORMAT=COMPRESSED;
/*!40101 SET character_set_client = #saved_cs_client */;
--
-- Dumping data for table `category`
--
/*!40000 ALTER TABLE `category` DISABLE KEYS */;
INSERT INTO `category` VALUES (1,'Italian_verb_forms',318746,3,0),(3,'English_adjectives',131200,8,0),(4,'Mycology',101,101,0),(5,'English_verbs',41925,23,0),(7,'English_nouns',338181,19,0),(11,'Candidates_for_speedy_deletion',10,2,0),(13,'Translation_requests_(Hungarian)',0,0,0),(14,'Translation_requests_(Korean)',0,0,0),(15,'Translation_requests_(Polish)',0,0,0),(16,'Translation_requests_(Slovak)',0,0,0),(17,'Translation_requ
Try
SQL Server Migration Assistant
https://learn.microsoft.com/en-us/sql/ssma/sql-server-migration-assistant?view=sql-server-ver15&viewFallbackFrom=sql-server-2019
You need an mysql odbc driver for that (of course), because you have to connect both servers.
You can try mysqldump
mysqldump --compatible=mssql
But that doesn't work everytime, and if that sql is to big you can get problems.
the rest -u and -p you should know waht you have to add evntually you need also --extended-insert=FALSE
Also phpmyadmin has an option to make an Backup in mssql Format, for that you switch to sql compatibility, but you need a websever plus pho for that.

utf8 data looks fine in mysql but is broken in rails

I'm setting a rails environment up for one of my colleagues, who's using a mac (in case that's relevant). I've pulled the data down from our live mysql database and made a local development database with that data. If i open the mysql console, and look at the data for a record which has extended charset characters in its name field, then it looks fine. However, in the rails console (and in a rails-generated web page) the encoding is broken: an endash is replaced by "—" for example.
The only rails config options i know about that are relevant to this is in config/database.yml. I currently have this set:
encoding: utf8
collation: utf8_general_ci
which makes it work fine on my machine for example. But like i say it's not working on my colleague's machine. Any ideas anyone?
EDIT 1: on the live server, where i copied the data FROM, the charset info looks like this:
mysql> show variables like 'char%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_filesystem | binary |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
EDIT 2: in response to #eggyal's comment i've done a couple of mysqldumps, which has been quite revealing. Here's the first dump:
$ mysqldump -u root -h127.0.0.1 dbname lessons --where="id=79510"
-- MySQL dump 10.11
--
-- Host: 127.0.0.1 Database: e_learning_resource_v3
-- ------------------------------------------------------
-- Server version 5.0.32-Debian_7etch4-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 `lessons`
--
DROP TABLE IF EXISTS `lessons`;
CREATE TABLE `lessons` (
`id` int(11) NOT NULL auto_increment,
`name` varchar(255) default NULL,
`description` text,
`user_id` int(11) default NULL,
`created_at` datetime default NULL,
`privacy` int(11) default '1',
`is_official` tinyint(1) default '0',
`is_readonly` tinyint(1) default NULL,
`comments_allowed` tinyint(1) default NULL,
`hours` int(11) default NULL,
`sessions` int(11) default NULL,
`updated_at` datetime default NULL,
`custom_menu_swf` varchar(255) default NULL,
`pupil_liked_at` datetime default NULL,
`user_liked_at` datetime default NULL,
`pupil_favorite_count` int(11) default '0',
`user_favorite_count` int(11) default '0',
`teacher_notes` text,
`pupil_notes` text,
PRIMARY KEY (`id`),
KEY `user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
--
-- Dumping data for table `lessons`
--
-- WHERE: id=79510
LOCK TABLES `lessons` WRITE;
/*!40000 ALTER TABLE `lessons` DISABLE KEYS */;
INSERT INTO `lessons` VALUES (79510,'Jazz–Man',NULL,NULL,'2014-04-03 12:08:05',1,0,NULL,NULL,NULL,NULL,'2014-04-03 12:08:05',NULL,NULL,NULL,0,0,NULL,NULL);
/*!40000 ALTER TABLE `lessons` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=#OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=#OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=#OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=#OLD_UNIQUE_CHECKS */;
/*!40101 SET CHARACTER_SET_CLIENT=#OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=#OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=#OLD_COLLATION_CONNECTION */;
/*!40111 SET SQL_NOTES=#OLD_SQL_NOTES */;
-- Dump completed on 2014-04-03 11:16:42
So, this was just a straight mysqldump and it's got the broken character in it (Jazz–Man) in the "INSERT INTO lessons" line.
I do it again with some extra options, and the data looks ok in the dump file:
$ mysqldump -u root -h127.0.0.1 dbname lessons --extended-insert --single-transaction --default-character-set=latin1 --skip-set-charset --where="id=79510"
-- MySQL dump 10.11
--
-- Host: 127.0.0.1 Database: e_learning_resource_v3
-- ------------------------------------------------------
-- Server version 5.0.32-Debian_7etch4-log
/*!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 `lessons`
--
DROP TABLE IF EXISTS `lessons`;
CREATE TABLE `lessons` (
`id` int(11) NOT NULL auto_increment,
`name` varchar(255) default NULL,
`description` text,
`user_id` int(11) default NULL,
`created_at` datetime default NULL,
`privacy` int(11) default '1',
`is_official` tinyint(1) default '0',
`is_readonly` tinyint(1) default NULL,
`comments_allowed` tinyint(1) default NULL,
`hours` int(11) default NULL,
`sessions` int(11) default NULL,
`updated_at` datetime default NULL,
`custom_menu_swf` varchar(255) default NULL,
`pupil_liked_at` datetime default NULL,
`user_liked_at` datetime default NULL,
`pupil_favorite_count` int(11) default '0',
`user_favorite_count` int(11) default '0',
`teacher_notes` text,
`pupil_notes` text,
PRIMARY KEY (`id`),
KEY `user_id` (`user_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
--
-- Dumping data for table `lessons`
--
-- WHERE: id=79510
LOCK TABLES `lessons` WRITE;
/*!40000 ALTER TABLE `lessons` DISABLE KEYS */;
INSERT INTO `lessons` VALUES (79510,'Jazz–Man',NULL,NULL,'2014-04-03 12:08:05',1,0,NULL,NULL,NULL,NULL,'2014-04-03 12:08:05',NULL,NULL,NULL,0,0,NULL,NULL);
/*!40000 ALTER TABLE `lessons` ENABLE KEYS */;
UNLOCK TABLES;
/*!40103 SET TIME_ZONE=#OLD_TIME_ZONE */;
/*!40101 SET SQL_MODE=#OLD_SQL_MODE */;
/*!40014 SET FOREIGN_KEY_CHECKS=#OLD_FOREIGN_KEY_CHECKS */;
/*!40014 SET UNIQUE_CHECKS=#OLD_UNIQUE_CHECKS */;
/*!40111 SET SQL_NOTES=#OLD_SQL_NOTES */;
-- Dump completed on 2014-04-03 11:18:20
So, it looks like the extra options did the trick:
--extended-insert --single-transaction --default-character-set=latin1 --skip-set-charset
When a MySQL client interacts with the server:
the server receives any text merely as a string of bytes; the client will have previously told it how such text would be encoded.
if the server then has to store that text in a table, it must transcode it to the encoding of the relevant column (if different).
if the client subsequently wants to retrieve such text, the server must transcode it to the encoding expected by the client.
If the encodings used by the client in steps 1 and 3 are the same (which is usually the case, especially when the client in both cases is the same application), then it often goes unnoticed if the client is using an encoding other than the one it said it would. For example, suppose the client tells MySQL that it will use latin1, but actually sends data in utf8:
The string 'Jazz–Man' is sent to the server in UTF-8 as 0x4a617a7ae280934d616e.
MySQL, decoding those bytes in Windows-1252, understands them to represent the string 'Jazz–Man'.
To store in a utf8 column, MySQL transcodes the string to its UTF-8 encoding 0x4a617a7ac3a2e282ace2809c4d616e. This can be verified by using SELECT HEX(name) FROM lessons WHERE id=79510.
When the client retrieves the value, MySQL thinks that it wants it in latin1 and so transcodes to the Windows-1252 encoding 0x4a617a7ae280934d616e.
When the client receives those bytes, it decodes them as UTF-8 and therefore understands the string to be 'Jazz–Man'.
Conclusion: the client doesn't realise anything is wrong. Problems are only detected when a different client (one that does not misstate its UTF-8 connection as latin1) tries to use the table. In your case, this occurred when mysqldump obtained an export of the data; using the --default-character-set=latin1 --skip-set-charset options effectively forced mysqldump to behave in the same broken way as your application, so it ended up with correctly encoded data.
To fix your issue going forward, you must:
Configure your application so that it correctly sets its MySQL connection character set (e.g. set encoding: utf8 in config/database.yml for Rails);
Recode the data in your database, e.g. UPDATE lessons SET name = BINARY CONVERT(name USING latin1) (note that this must be done for every misencoded text column).
Also note that you will probably want to perform these two actions atomically, which may require some thought.
I managed to fix this by semi-accident. When i was trying to import the sql data that had been done with the extra options relating to LATIN1 (see Edit 3 on my OP) i was getting an error message about the LC_TYPE variable (I didn't make a note of this exact error unfortunately). A bit of googling led me to set the following variables in his ~/.bash_profile file:
export LC_CTYPE=en_GB.UTF-8
export LANG=en_GB.UTF-8
After setting this, and opening a new console tab, i was able to import the data. But, it still looked wrong (though in a different way to before: ie some other messed up characters replacing the endash for example.) I scratched my head then did something else for a while.
Now, after he has restarted his laptop several times (because it's been a couple of weeks), it is all magically working. So, i think that a reboot fixed it. So, the answer is, i think, this:
Set these options in your rails config/database.yml file
encoding: utf8
collation: utf8_general_ci
Add these environment variables to ~/.bash_profile
export LC_CTYPE=en_GB.UTF-8
export LANG=en_GB.UTF-8
Add (or change if they are there already) these options to your mysql config (in this case, /Applications/MAMP PRO/MAMP PRO.app/Contents/Resources/my.cnf but a more common location would be /etc/mysql/my.cnf or /etc/my.cnf - look for it with locate my.cnf)
collation-server = utf8_unicode_ci
init-connect='SET NAMES utf8'
character-set-server = utf8
Now reboot your machine.
Then, when you do mysqldump, make sure you do it with these options (in addition to whatever other options you have)
--extended-insert --single-transaction --default-character-set=latin1 --skip-set-charset
Some of this may not be necessary, but i think it was all necessary for me!
Thanks to everyone who commented for your help.

Get errno 150 when restoring sql dump file

I've use MySQL Dump Distrib 5.1.45 to backup my database. It's generated a file a below:
-- MySQL dump 10.13 Distrib 5.1.45, for Win32 (ia32)
--
-- Host: localhost Database: SG
-- ------------------------------------------------------
-- Server version 5.5.16
/*!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 */;
DROP TABLE IF EXISTS `hist`;
/*!40101 SET #saved_cs_client = ##character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `hist` (
`Id` int(11) NOT NULL AUTO_INCREMENT,
`HistUi` int(11) DEFAULT NULL,
`StdModel` varchar(30) DEFAULT NULL,
PRIMARY KEY (`Id`),
KEY `StdModel` (`StdModel`),
CONSTRAINT `FKA0015AD86A02605F` FOREIGN KEY (`StdModel`) REFERENCES `std` (`Model`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = #saved_cs_client */;
LOCK TABLES `hist` WRITE;
/*!40000 ALTER TABLE `hist` DISABLE KEYS */;
/*!40000 ALTER TABLE `hist` ENABLE KEYS */;
UNLOCK TABLES;
DROP TABLE IF EXISTS `std`;
/*!40101 SET #saved_cs_client = ##character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `std` (
`Model` varchar(30) NOT NULL,
`Owner` varchar(30) DEFAULT NULL,
PRIMARY KEY (`Model`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = #saved_cs_client */;
But when I try to restore from that file, I fails and show a message such as:
ERROR 1005 (HY000): Can’t create table ‘SG.hist’ (errno: 150)
I try some solutions got from Google search but not work:
Add SET FOREIGN_KEY_CHECKS = 0; on top of dump file
Use mysql.exe from MySql Server 5.5
Use MySql Workbench
...
I wasted too may time on this issue but still can't find the root cause leading to the problem. I cannot use newer mysqldump.exe file to create dump file again, and don't want to change database structure now. A little change in sql dump file is acceptable.
Update:
Bring that file to other PCs which have the same MySQL server and it works fine. I tried to compare my.ini files, even copying my.ini file from another PC doesn't make it worked.
I had the same problem, which I believe was caused by tables that were expected to be created later in the same dump file already existing, perhaps with slightly different definitions. I dropped the database and recreated it from scratch and everything worked fine. Could this be your problem?

Using Script to load data into database -- sql

so I have a cpanel hosted database. My instructors have given us a script to load the IMDB database into our database. The file is a .sql file and it looks like this...
CREATE DATABASE IF NOT EXISTS `imdb` /*!40100 DEFAULT CHARACTER SET utf8 */;
USE `imdb`;
-- MySQL dump 10.13 Distrib 5.6.11, for Win32 (x86)
--
-- Host: localhost Database: imdb
-- ------------------------------------------------------
-- 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 `actors`
--
DROP TABLE IF EXISTS `actors`;
/*!40101 SET #saved_cs_client = ##character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `actors` (
`actorid` mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
`name` varchar(250) NOT NULL,
`sex` enum('M','F') DEFAULT NULL,
PRIMARY KEY (`actorid`),
KEY `name` (`name`(10))
) ENGINE=InnoDB AUTO_INCREMENT=2798731 DEFAULT CHARSET=utf8;
/*!40101 SET character_set_client = #saved_cs_client */;
--
-- Dumping data for table `actors`
--
LOCK TABLES `actors` WRITE;
/*!40000 ALTER TABLE `actors` DISABLE KEYS */;
INSERT INTO `actors` VALUES (1378,'Abagnale Jr., Frank','M'),(1837,'Abbasi, Riz','M')
etc..
So I go to import the .sql file on cpanel..
And i'm getting an error
I'm not really sure how to go about doing this. The instructions are very vague and no office hours...
Appreciate the help.
The issue with this database import is that the following line states the database that you are importing data into. It is currently set to imdb.
CREATE DATABASE IF NOT EXISTS `imdb`
In cPanel mysql databases (with database prefixing enabled) will have your username prefixed to the beginning of the database name and the user supplied database name is postfixed. In this case you can look at the top of PhpMyAdmin and see:
Database: gress2_hw2
This means you will need to update your SQL and replace imdb to gress2_hw2for the data to be imported into the database you are currently in like in the example below:
CREATE DATABASE IF NOT EXISTS `gress2_hw2`
Additionally if you remove this line the mysql server will import the data into the database currently selected by PhpMyAdmin.
I had to change to change the script to
CREATE DATABASE IF NOT EXISTS `gress2_hw2` /*!40100 DEFAULT CHARACTER SET utf8 */;
USE `gress2_hw2`;
Since that what i had originally named my database.