I have a WordPress website on my local WAMP server. But when I upload its database to live server, I get error
#1273 – Unknown collation: ‘utf8mb4_unicode_520_ci’
Any help would be appreciated!
I believe this error is caused because the local server and live server are running different versions of MySQL. To solve this:
Open the sql file in your text editor
Find and replace all utf8mb4_unicode_520_ci with utf8mb4_unicode_ci
Save and upload to a fresh mySql db
You can solve this by finding
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_520_ci;
in your .sql file, and swapping it with
ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;
In my case it turns out my
new server was running MySQL 5.5,
old server was running MySQL 5.6.
So I got this error when trying to import the .sql file I'd exported from my old server.
MySQL 5.5 does not support utf8mb4_unicode_520_ci, but
MySQL 5.6 does.
Updating to MySQL 5.6 on the new server solved collation the error !
If you want to retain MySQL 5.5, you can:
- make a copy of your exported .sql file
- replace instances of utf8mb4unicode520_ci and utf8mb4_unicode_520_ci
...with utf8mb4_unicode_ci
- import your updated .sql file.
Open the sql file in your text editor;
1. Search: utf8mb4_unicode_ci Replace: utf8_general_ci (Replace All)
2. Search: utf8mb4_unicode_520_ci Replace: utf8_general_ci (Replace All)
3. Search: utf8mb4 Replace: utf8 (Replace All)
Save and upload!
I experienced a challenge importing data into mysql exported using mysql workbench. It is a collation issue.
I solved this error by:
Opening the .sql file using text editor
Replacing "utf8mb4_0900_ai_ci" with "utf8mb4_general_ci".
Saving the file as .sql and importing it
It worked
easy replace
sed -i 's/utf8mb4_unicode_520_ci/utf8mb4_unicode_ci/g' your_sql_file.sql
just remove "520_"
utf8mb4_unicode_520_ci → utf8mb4_unicode_ci
I just opened the dump.sql file in Notepad++ and hit CTRL+H to find and replace the string "utf8mb4_0900_ai_ci" and replaced it with "utf8mb4_general_ci". Source link https://www.freakyjolly.com/resolved-when-i-faced-1273-unknown-collation-utf8mb4_0900_ai_ci-error/
this error is caused because the conflict of different versions of MySQL. To solve this:
Open the sql file in any text editor
Find and replace all utf8mb4_0900_ai_ci with utf8mb4_unicode_ci
Save and try new mySql db file
after that try again,it works fine for me
find and replace:
utf8mb4_unicode_520_ci
with
utf8_general_ci
in whole sql file
Getting collation error #1273 - Unknown collation: 'utf8mb4_unicode_520_ci' is caused by the difference of the MySQL version from which you export and our MySQL server to which you import. Basically, the Wordpress library for newer version checks to see what version of SQL your site is running on. If it uses MySQL version 5.6 or more, it assumes the use of a new and improved Unicode Collation Algorithm (UCA) called “utf8mb4_unicode_520_ci”. This is great unless you end up moving your WordPress site from a newer 5.6 version of MySQL to an older, pre 5.6 version of MySQL.
To resolve this you will either have to edit your SQL export file and do a search and replace, changing all instances of ‘utf8mb4_unicode_520_ci’ to ‘utf8mb4_unicode_ci’. Or follow the steps below if you have a PHPMyAdmin:
Click the Export tab for the database
Click the Custom radio button.
Go the section titled Format-specific options and change the drop-down for Database system or older MySQL server to maximize output compatibility with: from NONE to MYSQL40.
Scroll to the bottom and click GO.
I solved it this way, I opened the .sql file in a Notepad and clicked CTRL + H to find and replace the string "utf8mb4_0900_ai_ci" and replaced it with "utf8mb4_general_ci".
In my case I substitute it with utf8_general_ci with sed like this:
sed -i 's/utf8mb4_0900_ai_ci/utf8_general_ci/g' MY_DB.sql
sed -i 's/utf8mb4_unicode_520_ci/utf8_general_ci/g' MY_DB.sql
After that, I can import it without any issue.
Late to the party, but in case this happens with a WORDPRESS installation :
#1273 - Unknown collation: 'utf8mb4_unicode_520_ci
In phpmyadmin, under export method > Format-specific options( custom export )
Set to : MYSQL40
If you will try to import now, you now might get another error message :
1064 - You have an error in your SQL syntax; .....
That is because The older TYPE option that was synonymous with ENGINE was removed in MySQL 5.5.
Open your .sql file , search and replace all instances
from TYPE= to ENGINE=
Now the import should go smoothly.
1273 - Unknown collation: 'utf8mb4_0900_ai_ci'
in my case I was unable to import DB using
ENGINE = InnoDB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8 COLLATE = utf8_general_ci;
and
ENGINE = InnoDB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_0900_ai_ci;
both. But changing it to this in .SQL File resolved the problem
ENGINE=InnoDB DEFAULT CHARSET=latin1;
UPDATED
using 'utf8mb4_general_ci'resolved the problem
ENGINE = InnoDB AUTO_INCREMENT = 1 DEFAULT CHARSET = utf8mb4 COLLATE = utf8mb4_general_ci;
Very strange that all answers recommend replacing collation. Which is a very bad practice because you want to use the same MySQL version as the one in development and the one in production. Therefore, your local mysql server should be the same.
First of all, Execute the query SHOW COLLATION to check all the collations your server supports. If you're using xampp or any other similar tool to start your server, it might come shipped with maria db server instead of mysql server.
What you should do is replace your current mysql (which is really mariadb) by the real mysql one.
So what you should do is simply replace your maria db server by mysql server.
After a little investigation, I found that the MySQL server running on the destination is an older version than the source. So we got that the destination server doesn’t contain the required database collation.
Then we do a little tweak in the backup file to resolve this. Edit the database backup file(your_sql_file.sql) in a text editor and replace utf8mb4_0900_ai_ci with utf8mb4_general_ci and CHARSET=utf8mb4 with CHARSET=utf8.
I hope this solution might help you.
Use the sed command to replace text in files directly
Linux OS
sed -i 's/utf8mb4_unicode_520_ci/utf8mb4_general_ci/g' YOUR_SQL_FILE.sql
Mac OS
sed -i '' s/utf8mb4_unicode_520_ci/utf8mb4_general_ci/g' YOUR_SQL_FILE.sql
The help of this command i have fixed issue ERROR 1273 (HY000) at line 51: Unknown collation: 'utf8mb4_0900_ai_ci'
According to my experience, the destination's MySQL server is an older version than the source. The required database collation is not present on the destination server.
To fix this, we can make a small change to the backup file. Replace "utf8mb4 0900 ai ci" with "utf8mb4 general ci" and "CHARSET=utf8mb4" with "CHARSET=utf8" in the database backup file.
Replace the below string:
ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci;
with:
ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;
Save your file and restore the database.
I simply removed the COLLATE and other attributes and left only till ENGINE.
like the following
FROM:
ENGINE=InnoDB AUTO_INCREMENT=429 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci
TO:
ENGINE=InnoDB;
and it worked for me just fine.
Related
My supervisor was given a backup file from our company's cloud mysql database (adminstered by a 3rd party)
The file has a .mysql extension. I can view some of the data using Notepad++ so I know it contains valid data. In my research I discovered this a deprecated extension. Due to some reporting requirements, I was asked to move this data into Excel. I know enough about databases of the five of us in the shop to be considered the "expert" (a scary thought)
Research I've done leads me to believe I would be required to do a LAMP install to convert the mysql file to PDO which I think I can then convert to Excel. That seems like overkill to me.
Is there a more direct route? Load a legacy version of MySQL and hope I can do some conversion in the workbench? The file is a little over 500MB.
I typically develop industrial controls in Python or C#.
-- MySQL dump 10.13 Distrib 5.7.33, for Linux (x86_64)
--
-- Host: localhost Database: company_name
-- ------------------------------------------------------
-- Server version 5.7.33-0ubuntu0.18.04.1
DROP TABLE IF EXISTS `ACTIVEMQ_MSGS`;
/*!40101 SET #saved_cs_client = ##character_set_client */;
.
.
.
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `ACTIVEMQ_MSGS` (
`ID` bigint(20) NOT NULL,
`CONTAINER` varchar(250) DEFAULT NULL,
`MSGID_PROD` varchar(250) DEFAULT NULL,
`MSGID_SEQ` bigint(20) DEFAULT NULL,
`EXPIRATION` bigint(20) DEFAULT NULL,
`MSG` longblob,
`PRIORITY` bigint(20) DEFAULT NULL,
PRIMARY KEY (`ID`),
KEY `ACTIVEMQ_MSGS_MIDX` (`MSGID_PROD`,`MSGID_SEQ`),
KEY `ACTIVEMQ_MSGS_CIDX` (`CONTAINER`),
KEY `ACTIVEMQ_MSGS_EIDX` (`EXPIRATION`),
KEY `ACTIVEMQ_MSGS_PIDX` (`PRIORITY`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
.
.
.
LOCK TABLES `rh_blobs` WRITE;
/*!40000 ALTER TABLE `rh_blobs` DISABLE KEYS */;
INSERT INTO `rh_blobs` VALUES (data....)
INSERT INTO `rh_blobs` VALUES (data....)
Thanks to all for recommendations. Using mysql command line helped me solve the problem.
Install mysql on my desktop (Windows)
start mysql with the following. Entered root password at the prompt
cd c:\program files\mysql\mysql server 5.7\bin
mysql -u root -p
Create and restored the backup/archive file to a new database
create database company-name-report
use company-name-report
source c:\users\user_name\Downloads\company_name.mysql
Following #O. Jones advice, downloaded HeidiSQL and was able to view the data.
Should be a simple task now to export to CSV for use with Excel
Assuming your file contains the text of a bunch of SQL statements, here's what you need to do.
Stand up a MySQL server temporarily.
Run the SQL statements in your file, one after the other in order, against that server.
Issue a SQL statement to write out a comma-separated-value (.csv) file for each table that's populated by that file of yours.
Import those .csv files into Excel.
Get rid of the MySQL server.
The version of the MySQL server you use is almost certainly irrelevant.
MySQL Workbench or the HeidiSQL client program, among many others, give you the tools you need for steps 2-4.
In MySQL Workbench, right-click the table to export and choose Table Data Export Wizard. In the wizard, choose csv export. Choose comma for the field separator, CR for the line separator. Enclose strings in ", the double quote character. And for null and NULL, choose NO.
Several cloud providers offer quick and easy ways to stand up MySQL servers. For example, Digital Ocean offers MySQL servers for pennies an hour. And they charge by the hour. If this little project costs you as much as five US dollars, that will be a surprise.
Being a designer, I don't understand MySQL and have no ability to alter the database. Go easy!
CREATING THE ERROR
Exported a Concrete5 db (modified to run on php 7) from a server running MySQL 5.7.27
Imported the db into MAMP Pro 5.5.1 running MySQL 5.7.26 for local development
Import fails on time-related rows like this one...
CREATE TABLE `atDateTime` (
`avID` int(10) unsigned NOT NULL,
`value` datetime DEFAULT '0000-00-00 00:00:00',
PRIMARY KEY (`avID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8
ANSWERS FOUND
1. MYSQL 5.7+
Many answers say the error is because MySQL 5.7+ no longer accepts blank dates but the db is being exported from a server already running MySQL 5.7.27?
2. TIMEZONE ISSUE
Other answers suggest it's a Timezone difference but both the server and local Mac are running NZDT. MAMP Pro seems to use the system timezone.
3. QUERIOUS/SEQUAL PRO
Multiple db apps were tried incase issue was application-specific but both show the same errors.
QUESTION
Can anyone explain what the exact issue is (to a designer) and how to fix without altering the db?
MySQL 5.7 doesn't allow blank dates by default.
The db doesn't work in MAMP Pro because MySQL strict mode is enabled by default.
The db works on the live server because MySQL strict mode has been disabled.
The solution is to disable strict mode in MAMP Pro.
Disable MySQL strict mode and allow blank dates in MAMP Pro:
Shut down the MAMP Pro servers
Go File > Edit Templates> MySQL (my.conf) > MySQL Version you're using
In the first third of the file, look for (with square brackets)...
[mysqld]
Directly underneath, add sql_mode="" like this...
[mysqld]
sql_mode=""
This disables strict mode and allows blank dates
Save the file and close
Start the servers
Import your db
If you don't know the correct search terms; 'disable MySQL strict mode in MAMP Pro', you're left wandering in the wilderness for hours. Hope this helps other designers.
More reference: https://mampsupportforum.com/forums/latest/mamp-mamp-pro-disable-mysql-strict-mode
I want to convert my database to utf-8. What I have done up to now is set the server to read utf-8 and the database is converted by using this query:
ALTER DATABASE database_name CHARACTER SET utf8 COLLATE utf8_unicode_ci;
Now all new information is seen and the things that were broken are now fine. The problem is that the old data is seen as �. This, in my opinion, is due to the fact that the old data is written in windows-1251 (I think at least and I am not 100% sure).
I found out that I need to dump the data:
mysqldump -uroot -p database -r utf8.dump
and then import it:
mysql -uroot -p --default-character-set=utf8 database
mysql> SET names 'utf8'
mysql> SOURCE utf8.dump
This is what I saw from here: https://makandracards.com/makandra/595-dumping-and-importing-from-to-mysql-in-an-utf-8-safe-way
The problem is that I have absolutely no idea where and how to do this.
All I have access is to the web hosting control panel and I have not set up anything on my computer. Therefore, I have no idea how to connect the database to the command shell and so on. What next steps should I do to convert the data to utf-8? Please, any detailed explanation would be great due to the fact that this is the first time for me doing something like this.
// I have a Mac and a Windows machine, but not a Linux at the moment.
Thank you!
The charset and collation of the database are the default for any subsequently created tables. The table setting are the defaults for columns.
For each table, so this:
ALTER TABLE table_name CONVERT TO utf8mb4;
I want to move my MySQL database to an older version server (5.7 to 5.1).
I get errors because it is created using utf8mb4 .
If i manually change utf8mb4 to utf8 the data become unreadable because of multilinguality.
I have access only to phpMyAdmin in both servers so I can't use mysqldump.
Any ideas?
It seems I've figured out a solution.
Use at export mysql40 compatibility mode, replace utf8mb4 with utf8 and change the character set of tables from phpmyadmin to utf8_unicode_ci.
Hope this will save some time from a fellow in future.
Last week I migrated my db in another platform. I did a mysqldump export from phpmyadmin panel and then I imported it in a new platform using the bigdump script.
The sql dump file that I have imported was originally stored in a db that was setting in this manner:
MySQL charset: UTF-8 Unicode (utf8)
MySQL connection collation: utf8_unicode_ci
I exported the db choosing utf8 character set but if I look inside the mysqldump file for every table appears:
DEFAULT CHARSET=latin1
Now I have a problem with the accented letter (like à, è, ò, ì) that are displayed like ò , Ã...etc.
For manage my new db I use MySQL Workbench and if i prompt:
show variables like 'char%';
I see that all the values are set in utf8.
How can I solve the problem? I'm not a Mysql and db expert!
You can try changing the current character set of a table to the original:
alter table TABLE_NAME convert to character set utf8 collate utf8_unicode_ci;
Your tables seem to use latin1, despite the utf8 settings you mentioned. So you have several options here:
Take the created dump as is and send it to the server using the latin1 connection charset (not utf8). This will however create the tables with latin1 charset as they are on the source server.
Convert the dump to utf-8 if you have a tool that can do it. You have to change the charset settings for your tables in the script too, though.
Convert your tables to utf8 and do the dump again.
Combine 1 + 3, but convert your target tables instead. Useful if you cannot change the source tables.
Have you actually tried MySQL Workbench to restore the dump to your new server? I'm quite sure it should be able to handle this case with a latin1 encoded backup. See Server Administration section -> Data Import/Restore.