I'm trying to rename my table using this SQL. I'm using MySQL 5.1.41 on Windows XP.
USE 'bobby_tables';
ALTER TABLE gc_acompte_fournisseur
RENAME TO GC_Acompte_Fournisseur;
And the query claims to have executed correctly, but it lies! My table name is still all lower case!
What foul arcanery have I run afoul of that forbids me from capitalizing my tables?
It just how MySQL works on Windows:
http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html#sysvar_lower_case_table_names
lower_case_table_names
If set to 0, table names are stored as
specified and comparisons are case
sensitive. If set to 1, table names
are stored in lowercase on disk and
comparisons are not case sensitive. If
set to 2, table names are stored as
given but compared in lowercase. This
option also applies to database names
and table aliases. For additional
information, see Section 8.2.2,
“Identifier Case Sensitivity”.
You should not set this variable to 0 if you are running MySQL on a system
that has case-insensitive file names
(such as Windows or Mac OS X). If
you set this variable to 0 on such a
system and access MyISAM tablenames
using different lettercases, index
corruption may result. On Windows
the default value is 1. On Mac OS X,
the default value is 2.
If you are using InnoDB tables, you should set this variable to 1 on all
platforms to force names to be
converted to lowercase.
(Emphasis mine)
To rename/alter a table name in mysql, run following query:
RENAME TABLE tbl_name TO new_tbl_name
Example:
RENAME TABLE student TO pu_students
For reference: http://dev.mysql.com/doc/refman/5.0/en/rename-table.html
Thank you!
Related
i want to change table character set from 'utf8' to 'utf8mb4'
but each column has own character set setting(utf8)
so i need to change column character set to 'Table Default', but locking is the problem
help me to change column character set without table locking
there is over 100,000,000 rows in table
"Character set" is the encoding of the characters in bytes.
"Collation" is how to sort characters.
An INDEX on a VARCHAR is sorted by its collation, so changing the collation of a column requires rebuilding an index -- a non-trivial operation.
The difference between utf8 and utf8mb4 is relatively minor, but I don't think MySQL (hence RDS) has made a special case of that.
ALTER TABLE t CONVERT TO utf8mb4; sounds like the operation that you desire. That requires ALGORITHM=COPY, so it is 'locking'.
Look into pt-online-schema-change and gh-ost as a way of altering a table, even when it needs to "copy". These are essentially non-blocking. However, I do not know if they can be used with RDS. Also, because of JOINs and other cases where one table may need to be consistent with another, those tools may not be practical.
Another approach... Add another column(s); change your code to use both the old and new column(s). Meanwhile, gradually copy the old values to the new column(s); when this is finished, change your code again -- this time to use the new column(s) instead of the old. At some later date, worry about dropping the dead column(s).
Recent versions of MySQL have made significant changes in the speed of ALTER, so be sure to study what version RDS is derived from. In 5.6, ADD COLUMN can use ALGORITHM=INPLACE; in 8.0, ALGORITHM=INSTANT. I think either of those is non-"locking" for your purposes. (DROP COLUMN is not cheap; the issues with JOIN and rebuilding indexes are still up in the air.)
If you try one of these techniques, I strongly recommend you build a table with at least a million rows and try out all the steps (alter add, join, recreate index, alter drop column, etc) to verify what parts are "fast enough" and/or "non-locking".
I am trying to rename my tables in my DB to use camel case starting with a caps. So for example I need address to be Address and userinformation to UserInformation.
When I use the command
RENAME TABLE `address` TO `Address`
It spits back an error saying Table 'Address' already exists
Any way around this?
This issue results from case-insensitivity, those names are identical as far as the db is concerned. If you just want to standardize the names you can do so with an intermediate name:
RENAME TABLE `address` TO `Address_tempName`;
RENAME TABLE `Address_tempName` TO `Address`;
From MySql guide, you must check the system variable named lower_case_table_names before run RENAME TABLE
This variable is stored in my.ini file.
If this variable doesn't exist in my.ini file, you can add it
Ther default value is 0 and the possible value are 0, 1, 2
You can check its effect here
And if you see here guide advices you how apply a RENAME TABLE from T1 table into t1 table.
1.
When I ran this MYSQL syntax on windows it ran properly:
CREATE TABLE New
(
id bigint NOT NULL AUTO_INCREMENT,
timeUp datetime DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (id)
)
But when I tried running this code on Linux I got an error:
#1067 - Invalid default value for 'time'
2.
On windows the case is not sensitive eg. New and new both are considered to be same. But on linux the case is sensitive.
Configuration of Linux:
MySQL 5.5.33, phpMyAdmin: 4.0.5, PHP: 5.2.17
Configuration of Windows:
MySql: 5.6.11, phpMyAdmin: 4.0.4.1, PHP: 5.5.0
Is there any way to make them common for both systems? Or any alternative approach?
The DEFAULT CURRENT_TIMESTAMP support for a DATETIME (datatype) was added in MySQL 5.6.
In 5.5 and earlier versions, this applied only to TIMESTAMP (datatype) columns.
It is possible to use a BEFORE INSERT trigger in 5.5 to assign a default value to a column.
DELIMITER $$
CREATE TRIGGER ...
BEFORE INSERT ON mytable
FOR EACH ROW
BEGIN
IF NEW.mycol IS NULL THEN
SET NEW.mycol = NOW();
END IF;
END$$
Case sensitivity (of queries against values stored in columns) is due to the collation used for the column. Collations ending in _ci are case insensitive. For example latin1_swedish_ci is case insensitive, but latin1_general_cs is case sensitive.
The output from SHOW CREATE TABLE foo will show the character set and collation for the character type columns. This is specified at a per-column level. The "default" specified at the table level applies to new columns added to the table when the new column definition doesn't specify a characterset.
UPDATE
Kaii pointed out that my answer regarding "case sensitivity" deals with values stored within columns, and whether queries will return a value from a column containing a value of "New" will be returned with a predicate like "t.col = 'new'".
See Kaii's answer regarding identifiers (e.g. table names) being handled differently (by default) on Windows than on Linux.
As the DEFAULT CURRENT_TIMESTAMP question is already answered, i will only respond to the case-sensitivity mismatch in table names between windows and linux.
On Windows, file systems are by default case-insensitive.
But on Linux and other *NIX like Operating Systems, they are case-sensitive by default.
The reason why you get a mismatch in behaviour here is the file system, as each table is created as a separate file and the filesystem handles case-sensitivity for you.
MySQL has a parameter to override this behaviour:
For example, on Unix, you can have two different tables named my_table
and MY_TABLE, but on Windows these two names are considered identical.
To avoid data transfer problems arising from lettercase of database or
table names, you have two options:
Use lower_case_table_names=1 on all systems. The main disadvantage with this is that when you use SHOW TABLES or SHOW DATABASES, you do
not see the names in their original lettercase.
Use lower_case_table_names=0 on Unix and lower_case_table_names=2 on Windows. This preserves the lettercase of database and table names.
The disadvantage of this is that you must ensure that your statements
always refer to your database and table names with the correct
lettercase on Windows. If you transfer your statements to Unix, where
lettercase is significant, they do not work if the lettercase is
incorrect.Exception: If you are using InnoDB tables and you are trying to avoid these data transfer problems, you should set lower_case_table_names=1 on all platforms to force names to be converted to lowercase.
[...]
To avoid problems caused by such differences,
it is best to adopt a consistent convention, such as always creating
and referring to databases and tables using lowercase names. This
convention is recommended for maximum portability and ease of use.
This is an excerpt from the MySQL manual on the case sensitivity of identifiers
if you wants to default time to must change to timestamp in your datatype,
the datetime is going to display the user input of table...
http://dev.mysql.com/doc/refman/5.0/en/timestamp-initialization.html
http://dev.mysql.com/doc/refman/5.6/en/timestamp-initialization.html
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)
I'm playing with MySQL (curiosity, self-learning) and I've noticed a strange thing:
I want to create a table:
use `a`;
CREATE TABLE `Languages` (
`Id` int(11) NOT NULL AUTO_INCREMENT,
`LanguageName` char(10) NOT NULL DEFAULT '',
PRIMARY KEY (`Id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8;
but as the result, the table name is languages instead of Languages. Why ? Should I know something before create a table ?
Check the value of your lower_case_table_names system variable. If this variable has a value of 1, then MySQL converts all table names to lowercase for storage. More information on this behavior can be found here: MySQL Identifier Case Sensitivity
MySQL actually recommends this behavior as a way to avoid data transfer issues (from the doc linked above):
To avoid data transfer problems arising from lettercase of database or
table names, you have two options:
Use lower_case_table_names=1 on all systems. The main disadvantage
with this is that when you use SHOW TABLES or SHOW DATABASES, you do
not see the names in their original lettercase.
Use lower_case_table_names=0 on Unix and lower_case_table_names=2 on
Windows. This preserves the lettercase of database and table names.
The disadvantage of this is that you must ensure that your statements
always refer to your database and table names with the correct
lettercase on Windows. If you transfer your statements to Unix, where
lettercase is significant, they do not work if the lettercase is
incorrect.
SQL is case insensitive in general (keywords and names), so upper/lower cases should not matter. Since mysql maps tables to files (MyISAM tables at least) it makes difference wether you using a Linux or Windows system. Imho you should not create names, where case matters.