my host has just updated phpmyadmin to version 4.0.3. I don't know if it is related to the following problem.
I have a table 'users' which stores user data for the site and all data is now being stored as numbers. Where I had a username of 'rich' it is now '72696368' which is it's ascii code.
Any ideas why this might have happened? I have a lot of tables and have checked them all, it is only the users table that has been modified. It is not critical as I can still log in and accept new users etc but I would like to know why this is happening.
Thanks a lot
EDIT The collation is utf8_general_c
try adding this snippet to the script you are running in the line in which you create the schema
DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci
for example :
CREATE SCHEMA IF NOT EXISTS `my_schema` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;
Related
I am working on 2 servers each having similar configurations, Including mysql variables specific to character set and collation and both are on running mysql server and client 5.6.x. By default all tables are in latin1 including tables with only integer columns, But when I run
ALTER TABLE `table_name` CONVERT TO CHARACTER SET `utf8` COLLATE `utf8_unicode_ci`
for all tables in each server only one of the servers is converting all tables to utf8.
What I already tried:
Converted the default database character (character_set_database) set to utf8 before running the above listed command
Solution already worked for me (but still unsure why it worked)
ALTER TABLE `table_name` CHARACTER SET = `utf8` COLLATE `utf8_unicode_ci`
Finally there are 2 questions:
CONVERT TO CHARACTER SET is working in one server and not in other
Solution already worked for me which is similar to CONVERT TO CHARACTER SET with only one difference I have come across is, it doesn't implicitly convert the all the columns to specified character set.
Can someone please help me understand what is happening?
Thank you in advance.
IIRC, that was a bug that eventually was fixed. See bugs.mysql.com . (The bug probably existed since version 4.1, when CHARACTER SETs were really added.)
I prefer to be explicit in two places, thereby avoiding the issue you raise:
When doing CREATE TABLE, I explicitly say what CHARACTER SET I need. This avoids depending on the default established when the database was created, perhaps years ago.
When adding a column (ALTER TABLE ADD COLUMN ...), I check (via SHOW CREATE TABLE) to see if the table already has the desired charset. Even so, I might explicitly state CHARACTER SET for the column. Again, I don't trust the history of the table.
Note: I am performing these queries from explicit SQL, not from some UI that might be "helping" me.
Follow on
#HBK found http://bugs.mysql.com/bug.php?id=73153 . From it, I suspect this is what 'should be' done by the user:
ALTER TABLE ...
CONVERT TO ...
DEFAULT CHARACTER SET ...; -- Do this also
I need to store some data in a MySQL table, but I got some problems with theese kind of characters: "ā" "æ" "ō" "ĕ" (and so on)
Till now I had theese data stored in a SQLlite database and it was great because all was good, but now I'm trying to export it in a MySQL DB, but the strange chars are stored not in the good way, even if I tried different char encode. (UTF-8, UTF-16, latin blah blah)
Does anyone know the correct way to do so?
thanks a lot!!
utf8 needs to be established in about 4 places.
The column(s) in the database -- Use SHOW CREATE TABLE to verify that they are explicitly set to utf8, or defaulted from the table definition. (It is not enough to change the database default.)
The connection between the client and the server. See SET NAMES utf8.
The bytes you have.
If you are displaying the text in a web page, check the <meta> tag.
Either you can switch to BLOB datatype, or if you insist on using TEXT/VARCHAR/CHAR then you need to change charset of your table and database as shown below.
CREATE DATABASE mydbname
CHARACTER SET utf8
COLLATE utf8_general_ci;
USE mydbname;
CREATE TABLE `mytable` (
`data` varchar(200) COLLATE utf8_unicode_ci NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
If you already have a database with utf8 charset and collation set to utf8_general_ci then you can simply alter your table as mentioned below:
ALTER TABLE `mytable` CHANGE `data` `data` VARCHAR(100)
CHARSET utf8 COLLATE utf8_general_ci DEFAULT '' NOT NULL;
I have a MySQL table CHINESE with DEFAULT CHARSET=latin1 and it has a column NAME with CHARACTER SET latin1. I have huge amount to data stored in this table. Around a million rows. And, I want to execute the following commands on my database:
ALTER DATABASE <DATABASE_NAME> DEFAULT CHARACTER SET utf8
ALTER TABLE CHINESE DEFAULT CHARACTER SET utf8
ALTER TABLE CHINESE MODIFY NAME VARCHAR(30) CHARACTER SET utf8
Considering the fact that I have huge amount of data stored in this database. Should I run these commands on my database? Will these commands lock the database in any way?
I am using Java to query and insert values in database. Will appending ?useUnicode=yes&characterEncoding=UTF-8 in URI string help me?
It will take a long time,
I think is it is the best that you export a .sql out and don't the trans-code there replace latin1 to utf8 , then import back in a temp table. Finally swap the name of they.
I understand function of command collate (a little). It is truth that I did not test if it is possible to have tables with various collation (or even various charset) inside one DB.
But I found that (at least in phpmyadmin) when I create any DB, I set its charset and collation - and if I miss this command in CREATE TABLE ..., then automatically will be set collation set in creation of DB.
So, my question is: What is sense of presence of command collate in sql of CREATE TABLE ... if it can be missing there - and is recommended to have collate in CREATE TABLE ... or is it irrelevant?
In SQL Server if you don't specify the COLLATE it is defaulted to what ever DB is set to. Thus there is no danger in not specifying.
In MySQL behavior is the same:
The table character set and collation are used as default values for
column definitions if the column character set and collation are not
specified in individual column definitions. MySQL Reference
Collate is only used when you want to specify to non-default value. If all you are using is English character set than you have nothing to worry about it. If you store data from multiple languages than you have specify specific collation to ensure what characters are stored correctly.
When I started my website I set all the table columns to "utf8_general_ci" thinking this would make everything store in UTF8.
According to the mysql_client_encoding() function in PHP, I've been using the latin1 for my connection all along.
I understand this isn't a new problem. My question is how do I correctly update my database so that it utf8 and without affecting the data that exists in my tables?
There are a bunch of answers StackOverflow but a lot I find vague. A couple more helpful ones were:
Query all data and update as UTF8 https://stackoverflow.com/a/2335254/158126
Use a script built to convert tables https://stackoverflow.com/a/13400547/158126
In your experience, what have you done to fix this issue and retain all user data in the MySQL tables?
For your situation, I'd suggest trying to following for each bad column (connected over a utf8 connection):
// create a new column to store the latin1
alter table <table> add <column-latin1> <length> character set latin1;
// copy the utf8 data into the latin1 column without charset conversion
update <table> set <column-latin1> = binary <column-utf8>;
// verify the latin1 data looks OK
select <column-latin1> from <table>;
// copy the latin1 column into the utf8 column WITH charset conversion
update <table> set <column-utf8> = <column-latin1>;
// verify the new, properly encoded UTF8 data looks OK
select <column-latin1> from <table>;
// remove the temporary columns
alter <table> drop <column-latin1>;
And set your clients to use a UTF8 connection.