mySQL. MariaDB Server version
I want to run the following command in mySQL, but there is an error in my syntax that phpMyAdmin console states is related to MariaDB server version.
Alter table page modify column page_title convert to character set latin1_general_ci
How to tailor a mySQL script to MariaDB?
The syntax is indeed incorrect, it is not specific to MariaDB, you would have an error with MySQL as well.
You are mixing up different operations. Either you want to change the whole table (all character columns), and then it is
ALTER TABLE page CONVERT TO CHARACTER SET <character set>
or you want to change the column, and then it is
ALTER TABLE page MODIFY COLUMN page_title <column type> CHARACTER SET <character set>
Please read the documentation carefully to make sure the command that you choose does what you want, it is not always obvious.
Also, latin1_general_ci is not a character set, so you will have another error when you fix the syntax one.
Related
Is there a more appropriate Liquibase XML way of altering a table's character set?
Right now I'm using
<changeSet>
<sql>alter table <table_name> convert to character set utf8 collate utf8_unicode_ci;</sql>
</changeSet>
Is there something like
<modifyTable changeSet=utf8 />
Currently, Liquibase has no specific changeset type for altering a table's character set, so doing it in native SQL is the right way to go. However, since I am not that familiar with MySQL/MariaDB, I cannot predict how MySQL will treat existing data in your table.
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
After importing an Excel table that contained some special characters (like carriage returns or line feeds) in the headers row, it seems that the phpMyAdmin utility handled this situation silently by inserting those chars in the field's name.
The problem arose later when I tried to import the table into other environments/tools like data integrators, etc. For example, the column "Date Start" was imported into the table as "Date\nStart", with a LINE FEED in the middle.
The field rename operation through phpMyAdmin fails with this error:
**\#1054 - Unknown column 'Date Start' in 'mytable'**
The obvious workaround would be to edit the original Excel file by hand (removing LF's) then reimporting the table in MySql as before, but I'm in the position of needing to refresh the schema while preserving the data in the table.
Next I tried this from an SQL panel in phpMyAdmin (note the \n in the field name, VARCHAR(16) is just an example, DATETIME or INT should work as well):
ALTER TABLE mytable CHANGE `Date\nStart` `Date Start` VARCHAR(16)
but again it gives error #1054 - Unknown column 'Date\nStart' in 'mytable'
I also checked the INFORMATION_SCHEMA db, but as #Steve stated below, it's a read-only database.
I'm using MySql 5.5.32 and phpMyAdmin 4.0.4.1 with a Win7 desktop. Any suggestions?
First of all, by reading the MySql manual you can appreciate (or hate) the extreme flexibility allowed by the naming rules, details on the special characters that are/aren't allowed in a table and column names can be found in this manual page:
https://dev.mysql.com/doc/refman/5.5/en/identifiers.html
After several attempts escaping the CR character I've found a solution that works from the phpMyAdmin SQL pane, I think it should work on command-line sessions as well (didn't try that).
In case you inadvertently created or imported columns with CR's in the name, it is possible to fix it by typing the ENTER key within the column name, inside the SQL ALTER TABLE statement (you MUST enclose names in backticks for this trick to work).
Example: To replace the unwanted 'Date\nStart' column name with 'Date Start' you should type this (please note, the CR/Enter at the end of the first line!):
ALTER TABLE mybuggytable CHANGE `Date
Start` `Date Start` VARCHAR(16)
As explained above, you can spot columns with CR's embedded with this statement:
USE INFORMATION_SCHEMA; SELECT * FROM COLUMNS WHERE COLUMN_NAME like '%\n%'
I typed the ALTER TABLE command in the my phpMyAdmin SQL pane, and it just worked fine.
I thought you couldn't write to INFORMATION_SCHEMA because of a permission issue, but after reading the MySQL Manual I realise this is expected behavior as the manual states:
Although you can select INFORMATION_SCHEMA as the default database with a USE statement, you can only read the contents of tables, not perform INSERT, UPDATE, or DELETE operations on them.
To achieve a table rename by using the RENAME TABLE command, first run a select query to find all the tables that need changing and then rename them replacing the carnage return with a space character.
To rename just a column from within a table the ALTER TABLE command can be used with the CHANGE COLUMN parameters, for example:
ALTER TABLE table_name CHANGE COLUMN 'Date\nStart' 'Date Start' DATETIME
I know you've already said that is the command you need, so I've tested this myself by firstly selecting the tables and then running the ALTER TABLE command and it worked fine. I was using the command line interface, so maybe the problem lies with phpMyAdmin - can you confirm it isn't encoding or escaping \n?
Here is what I tested via the command line and worked OK:
SELECT COLUMN_NAME
FROM `INFORMATION_SCHEMA`.`COLUMNS`
WHERE TABLE_SCHEMA = 'test_345'
AND TABLE_NAME LIKE '%\n%';
ALTER TABLE test_table1 CHANGE COLUMN 'Date\nStart' 'Date Start' DATETIME;
Either of these could be wrapped up into a routine should you think this would be useful in the future.
I created a database schema using MySQL Workbench's data modeling tool. When it generates the SQL CREATE statements, it generates "default character set = latin1;" for some tables, e.g.:
-- -----------------------------------------------------
-- Table `moocdb`.`resource_types`
-- -----------------------------------------------------
CREATE TABLE IF NOT EXISTS `moocdb`.`resource_types` (
`resource_type_id` INT(11) NOT NULL,
`resource_type_name` VARCHAR(20) CHARACTER SET 'utf8' NOT NULL,
PRIMARY KEY (`resource_type_id`))
ENGINE = InnoDB
default character set = latin1;
How can I change it to the schema's default character set? (I found where to change the schema's default character set, but not the table's)
As a side note:
Note: Since MySQL 5.5.3 you should use utf8mb4
rather than utf8. They both refer to the UTF-8 encoding, but the
older utf8 had a MySQL-specific limitation preventing use of
characters numbered above 0xFFFD.
You can set the used charset/collation combination in the table editor. You have to expand the header (which is by default collapsed to save space) to be able to change it. See this screenshot:
Thanks a lot for this topic : it saves me a lot of time (I searched the header that was just collapsed by default).
I just want to say that you can specify for the table collation the option : schema default (the first option in the collation drop list).
And then, you can specify too the collation for the text type fields : table default.
With that, you can control the collation of your database with just the global schema collation parameter.
(my mysql workbench version : 6.1.7 revision 11891 build 1788)
Enjoy
Expand the database. Select the table from the tree view-> Right click and select alter table. You will get the following window shown in the screen shot. Here you can change the charset.
To change the entire database in the work bench...
In "Model Overview", under "Physical Schemata", right-click the database and select "Edit Schema...". Define the character set to the "Collation"-field. (MySQL Workbench 5.2.35)
Answered here:
https://stackoverflow.com/a/8149026/5579664
When you open your model, double click (or right click and edit) on MySQL schema, and MySQL Workbench show you, settings for Charset/Collation like as figure
I just saw that MySQL 5.5 offers utf8_general_mysql500_ci as collation.
What is the difference to other collations like utf8_general_ci?
Should I better use utf8_general_mysql500_ci?
As documented under Changes in MySQL 5.5.21:
New utf8_general_mysql500_ci and ucs2_general_mysql500_ci collations have been added that preserve the behavior of utf8_general_ci and ucs2_general_ci from versions of MySQL previous to 5.1.24. Bug #27877 corrected an error in the original collations but introduced an incompatibility for columns that contain German 'ß' LATIN SMALL LETTER SHARP S. (As a result of the fix, that character compares equal to characters with which it previously compared different.) A symptom of the problem after upgrading to MySQL 5.1.24 or newer from a version older than 5.1.24 is that CHECK TABLE produces this error:
Table upgrade required.
Please do "REPAIR TABLE `t`" or dump/reload to fix it!
Unfortunately, REPAIR TABLE could not fix the problem. The new collations permit older tables created before MySQL 5.1.24 to be upgraded to current versions of MySQL.
To convert an affected table after a binary upgrade that leaves the table files in place, alter the table to use the new collation. Suppose that the table t1 contains one or more problematic utf8 columns. To convert the table at the table level, use a statement like this:
ALTER TABLE t1
CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci;
To apply the change on a column-specific basis, use a statement like this (be sure to repeat the column definition as originally specified except for the COLLATE clause):
ALTER TABLE t1
MODIFY c1 CHAR(N) CHARACTER SET utf8 COLLATE utf8_general_mysql500_ci;
To upgrade the table using a dump and reload procedure, dump the table using mysqldump, modify the CREATE TABLE statement in the dump file to use the new collation, and reload the table.
After making the appropriate changes, CHECK TABLE should report no error.
For more information, see Checking Whether Tables or Indexes Must Be Rebuilt, and Rebuilding or Repairing Tables or Indexes. (Bug #43593, Bug #11752408)