Related
I have researched a lot and what I understand to make database tables name sensitive, you have to set the variable lower_case_table_names=0.
Im on osX. I did this change in my.cnf.
After that, if I run
select * from users
I get results. While if I run:
select * from Users
I get error saying table doesn't exist.
However, for a particular database, the case sensitivity doesnt affect. I can use any case I will never receive errors. Why? I could have a look at the big sql-file used to import the database and try to find out if there are specific directives to ignore case sensitivity (?).
Anyway, why you think the case sensitivity applies for all database but not the one Im interested in? One of those that does case sensitivity is InnoDB. While the one that doesnt care about this is MyIsam. Could it be the reason? Any work around in that case?
Tables and Columns are Case Sensitive in Linux! To make them case insensitive, follow this:
Open terminal and edit /etc/mysql/my.cnf
sudo nano /etc/mysql/my.cnf
Underneath the [mysqld] section, add:
lower_case_table_names = 1
Restart mysql
sudo /etc/init.d/mysql restart
Then check it here:
mysqladmin -u root -p variables
Just altering the lower_case_table_names setting isn't enough. It needs to be done before you import your database(s).
The MySQL 5.7 documentation lists a procedure for moving between Windows and Linux/UNIX. A note about Mac OSX from that reference:
One notable exception is OS X, which is Unix-based but uses a default
file system type (HFS+) that is not case sensitive. However, OS X also
supports UFS volumes, which are case sensitive just as on any Unix.
Review the manual page to ensure that your desired rules for enforcing case sensitivity are followed. Take a look and verify that you did these steps in the correct order:
To convert one or more entire databases, dump them before setting
lower_case_table_names, then drop the databases, and reload them after
setting lower_case_table_names:
1 - Use mysqldump to dump each database:
mysqldump --databases db1 > db1.sql
mysqldump --databases db2 >
db2.sql
... Do this for each database that must be recreated.
2 - Use DROP DATABASE to drop each database.
3 - Stop the server, set lower_case_table_names in the [mysqld] section of your \etc\mysql\my.cnf file, and restart the server.
4 - Reload the dump file for each database. Because lower_case_table_names
is set, each database and table name will be converted to lowercase as
it is recreated:
mysql < db1.sql
mysql < db2.sql
Concerning the MySQL System Variable lower_case_table_names Server Variable (or setting):
Additional References:
MySQL case sensitive table names on Linux
How to make MySQL table name case insensitive in Ubuntu?
MacOsx 10.13, docker 3.0.1.
Changing lower_case_table_names to 0 did not help me. Mysql gave error
[ERROR] The server option ‘lower_case_table_names’ is configured to use case sensitive table names but the data directory is on a case-insensitive file system which is an unsupported combination. Please consider either using a case sensitive file system for your data directory or switching to a case-insensitive table name mode.
Turning this setting Use gRPC FUSE for file sharing off in docker settings helped:
The case sensitivity of database and table names depends on the underlying OS and file system.
On Windows they are not case sensitive. On Linux they are case sensitive.
OSX is somewhere in the middle; the HFS file system supports both case-sensitive and case-insensitive file names (not on the same time though). It depends on how it was formatted.
By default, table aliases are case-sensitive on Unix, but not so on Windows or macOS. And you can't force this on OSX.
The MySql documentation gives the following recommendation:
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.
In MySQL, databases correspond to directories within the data directory. Each table within a database corresponds to at least one file within the database directory (and possibly more, depending on the storage engine). Triggers also correspond to files. Consequently, the case sensitivity of the underlying operating system plays a part in the case sensitivity of database, table, and trigger names. This means such names are not case-sensitive in Windows but are case-sensitive in most varieties of Unix. One notable exception is macOS, which is Unix-based but uses a default file system type (HFS+) that is not case-sensitive. However, macOS also supports UFS volumes, which are case-sensitive just as on any Unix. See Section 1.7.1, “MySQL Extensions to Standard SQL”. The lower_case_table_names system variable also affects how the server handles identifier case sensitivity, as described later in this section.
The recommended is use lower_case_table_names=1 on all systems, but the disadvantage with this is that when you use SHOW TABLES or SHOW DATABASES, you don't see the names in the original case.
the variable lower_case_table_names is 0 by default, which means table names are stored as specified and comparisons are case-sensitive.
that is the possible values:
0: table names are stored as specified and comparisons are case-sensitive.
1: table names are stored in lowercase on disk and comparisons are not case-sensitive.
2: table names are stored as given but compared in lowercase. This option also applies to database names and table aliases.
On Windows the default value is 1. On macOS, the default value is 2. On Linux, a value of 2 is not supported; the server forces the value to 0 instead.
and here are your answer
You should not set lower_case_table_names to 0 if you are running MySQL on a system where the data directory resides on a case-insensitive file system (such as on Windows or macOS). It is an unsupported combination that could result in a hang condition when running an INSERT INTO ... SELECT ... FROM tbl_name operation with the wrong tbl_name lettercase. With MyISAM, accessing table names using different lettercases could cause index corruption.
An error message is printed and the server exits if you attempt to start the server with --lower_case_table_names=0 on a case-insensitive file system.
you can change this in my.cnf file, and you can find it using following command (if you are using unix-based system)
mysql --help | grep cnf
References:
MySQL 5.7 Reference Manual Identifier Case Sensitivity
MySQL 5.7 Reference Manual 5.1.7 Server System Variables
However, for a particular database, the case sensitivity doesnt
affect. I can use any case I will never receive errors. Why?
This is because this database is simply created with option of case-insensitivity (by default). You need first to put case-sensitive option in the top of sql create script before the database creation, so the DBMS takes care.
Locate file at /etc/mysql/my.cnf
Edit the file by adding the following lines:
[mysqld]
lower_case_table_names=1
sudo /etc/init.d/mysql restart
You might need to re-create these tables to make it work
mysql manual states:
If you plan to set the lower_case_table_names system variable to 1 on Unix, you must first convert your old database and table names to lowercase before stopping mysqld and restarting it with the new variable setting.
In any new APFS based Mac you can do this which appears to be working. The following will create a new volume that which is case-sensitive (APFSX) that you can use for your volume data. Note: You should do this in a fresh directory.
mkdir <docker volume directory>
sudo diskutil apfs addVolume disk1 APFSX docker -mountpoint <docker volume directory>
sudo chown -R $(id -u):$(id -g) <docker volume directory>
Ref: Feature to opt-in into a case sensitive file-system (osxfs) on a volume mount
Only solution on MacOS goes neither over lower_case_table_names nor else settings of MySQL DBMS.
You need a case sensitive file system (volume). But fortunately it's easy to create it under MacOS:
start the 'Disk Utility'
Unter a main APFS-Container add a new APFS volume with case sensitivity (assume, we name it 'MysqlData', you can also define the size quota for this volume)
move all the database binary data to this volume (in a directory in this volume i.e. /Volumes/MysqlData/data)
make a symbolic link (assume our mysql data directory is /usr/local/mysql/data) to this volume:
i.e.
/usr/local/mysql/data -> /Volumes/MysqlData/data
DO A BACKUP OF /usr/local/mysql/data BEFORE!!!
start MySQL DBMS and load/import a DB (maybe you have to remove these DBs before) with uppercase tables
voila: you will finally see these tables with uppercase
I have researched a lot and what I understand to make database tables name sensitive, you have to set the variable lower_case_table_names=0.
Im on osX. I did this change in my.cnf.
After that, if I run
select * from users
I get results. While if I run:
select * from Users
I get error saying table doesn't exist.
However, for a particular database, the case sensitivity doesnt affect. I can use any case I will never receive errors. Why? I could have a look at the big sql-file used to import the database and try to find out if there are specific directives to ignore case sensitivity (?).
Anyway, why you think the case sensitivity applies for all database but not the one Im interested in? One of those that does case sensitivity is InnoDB. While the one that doesnt care about this is MyIsam. Could it be the reason? Any work around in that case?
Tables and Columns are Case Sensitive in Linux! To make them case insensitive, follow this:
Open terminal and edit /etc/mysql/my.cnf
sudo nano /etc/mysql/my.cnf
Underneath the [mysqld] section, add:
lower_case_table_names = 1
Restart mysql
sudo /etc/init.d/mysql restart
Then check it here:
mysqladmin -u root -p variables
Just altering the lower_case_table_names setting isn't enough. It needs to be done before you import your database(s).
The MySQL 5.7 documentation lists a procedure for moving between Windows and Linux/UNIX. A note about Mac OSX from that reference:
One notable exception is OS X, which is Unix-based but uses a default
file system type (HFS+) that is not case sensitive. However, OS X also
supports UFS volumes, which are case sensitive just as on any Unix.
Review the manual page to ensure that your desired rules for enforcing case sensitivity are followed. Take a look and verify that you did these steps in the correct order:
To convert one or more entire databases, dump them before setting
lower_case_table_names, then drop the databases, and reload them after
setting lower_case_table_names:
1 - Use mysqldump to dump each database:
mysqldump --databases db1 > db1.sql
mysqldump --databases db2 >
db2.sql
... Do this for each database that must be recreated.
2 - Use DROP DATABASE to drop each database.
3 - Stop the server, set lower_case_table_names in the [mysqld] section of your \etc\mysql\my.cnf file, and restart the server.
4 - Reload the dump file for each database. Because lower_case_table_names
is set, each database and table name will be converted to lowercase as
it is recreated:
mysql < db1.sql
mysql < db2.sql
Concerning the MySQL System Variable lower_case_table_names Server Variable (or setting):
Additional References:
MySQL case sensitive table names on Linux
How to make MySQL table name case insensitive in Ubuntu?
MacOsx 10.13, docker 3.0.1.
Changing lower_case_table_names to 0 did not help me. Mysql gave error
[ERROR] The server option ‘lower_case_table_names’ is configured to use case sensitive table names but the data directory is on a case-insensitive file system which is an unsupported combination. Please consider either using a case sensitive file system for your data directory or switching to a case-insensitive table name mode.
Turning this setting Use gRPC FUSE for file sharing off in docker settings helped:
The case sensitivity of database and table names depends on the underlying OS and file system.
On Windows they are not case sensitive. On Linux they are case sensitive.
OSX is somewhere in the middle; the HFS file system supports both case-sensitive and case-insensitive file names (not on the same time though). It depends on how it was formatted.
By default, table aliases are case-sensitive on Unix, but not so on Windows or macOS. And you can't force this on OSX.
The MySql documentation gives the following recommendation:
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.
In MySQL, databases correspond to directories within the data directory. Each table within a database corresponds to at least one file within the database directory (and possibly more, depending on the storage engine). Triggers also correspond to files. Consequently, the case sensitivity of the underlying operating system plays a part in the case sensitivity of database, table, and trigger names. This means such names are not case-sensitive in Windows but are case-sensitive in most varieties of Unix. One notable exception is macOS, which is Unix-based but uses a default file system type (HFS+) that is not case-sensitive. However, macOS also supports UFS volumes, which are case-sensitive just as on any Unix. See Section 1.7.1, “MySQL Extensions to Standard SQL”. The lower_case_table_names system variable also affects how the server handles identifier case sensitivity, as described later in this section.
The recommended is use lower_case_table_names=1 on all systems, but the disadvantage with this is that when you use SHOW TABLES or SHOW DATABASES, you don't see the names in the original case.
the variable lower_case_table_names is 0 by default, which means table names are stored as specified and comparisons are case-sensitive.
that is the possible values:
0: table names are stored as specified and comparisons are case-sensitive.
1: table names are stored in lowercase on disk and comparisons are not case-sensitive.
2: table names are stored as given but compared in lowercase. This option also applies to database names and table aliases.
On Windows the default value is 1. On macOS, the default value is 2. On Linux, a value of 2 is not supported; the server forces the value to 0 instead.
and here are your answer
You should not set lower_case_table_names to 0 if you are running MySQL on a system where the data directory resides on a case-insensitive file system (such as on Windows or macOS). It is an unsupported combination that could result in a hang condition when running an INSERT INTO ... SELECT ... FROM tbl_name operation with the wrong tbl_name lettercase. With MyISAM, accessing table names using different lettercases could cause index corruption.
An error message is printed and the server exits if you attempt to start the server with --lower_case_table_names=0 on a case-insensitive file system.
you can change this in my.cnf file, and you can find it using following command (if you are using unix-based system)
mysql --help | grep cnf
References:
MySQL 5.7 Reference Manual Identifier Case Sensitivity
MySQL 5.7 Reference Manual 5.1.7 Server System Variables
However, for a particular database, the case sensitivity doesnt
affect. I can use any case I will never receive errors. Why?
This is because this database is simply created with option of case-insensitivity (by default). You need first to put case-sensitive option in the top of sql create script before the database creation, so the DBMS takes care.
Locate file at /etc/mysql/my.cnf
Edit the file by adding the following lines:
[mysqld]
lower_case_table_names=1
sudo /etc/init.d/mysql restart
You might need to re-create these tables to make it work
mysql manual states:
If you plan to set the lower_case_table_names system variable to 1 on Unix, you must first convert your old database and table names to lowercase before stopping mysqld and restarting it with the new variable setting.
In any new APFS based Mac you can do this which appears to be working. The following will create a new volume that which is case-sensitive (APFSX) that you can use for your volume data. Note: You should do this in a fresh directory.
mkdir <docker volume directory>
sudo diskutil apfs addVolume disk1 APFSX docker -mountpoint <docker volume directory>
sudo chown -R $(id -u):$(id -g) <docker volume directory>
Ref: Feature to opt-in into a case sensitive file-system (osxfs) on a volume mount
Only solution on MacOS goes neither over lower_case_table_names nor else settings of MySQL DBMS.
You need a case sensitive file system (volume). But fortunately it's easy to create it under MacOS:
start the 'Disk Utility'
Unter a main APFS-Container add a new APFS volume with case sensitivity (assume, we name it 'MysqlData', you can also define the size quota for this volume)
move all the database binary data to this volume (in a directory in this volume i.e. /Volumes/MysqlData/data)
make a symbolic link (assume our mysql data directory is /usr/local/mysql/data) to this volume:
i.e.
/usr/local/mysql/data -> /Volumes/MysqlData/data
DO A BACKUP OF /usr/local/mysql/data BEFORE!!!
start MySQL DBMS and load/import a DB (maybe you have to remove these DBs before) with uppercase tables
voila: you will finally see these tables with uppercase
I have installed MySql Workbench 6.2 with MySql version 5.6 on my Windows 7 64-bit.
I would like to use Capital letters in my database name and table names. So I need to set the variable lower_case_table_names to 2. When I look at my Options file's General tab, it looks like the following:
Clicking Apply opens a dialog that says "There Are No Changes".
Regardless, when I try to create a database with a Capital letter, I get the warning:
The server is configured with lower_case_table_names=1 which only
allows lowercase characters in schema and table names.
I have a feeling the my.ini file on the server differs from the one mentioned in the Options File configuration. When I try to add this variable manually
inside my my.ini file, I see the text below:
# *** DO NOT EDIT THIS FILE. It's a template which will be copied to the
# *** default location during install, and will be replaced if you
# *** upgrade to a newer version of MySQL.
This is how I have been stuck in creating my schema for a few days now.
In Windows, table naming is case-insensitive. That is, your Customer table and your customer table will always be the same on Windows. That's a limitation of the NT File System. This applies when your MySQL server is running on a Windows platform. It doesn't matter where your workbench client is running.
(You can use mixed-case table names for different tables on Linux, BSD, and the like, but it's considered very bad practice: only do that if you want to drive your colleagues crazy. So be careful.)
If you leave this lower_case_table_names setting alone, you can use mixed case in your table names without problems.
The my.ini file the server actually uses when it starts is usually found in the data directory. The installation procedure can copy a preloaded version of that file, like my_large.ini on top of my.ini depending on what you are trying to do.
You can't even start mysqld after changing the lower_case_table_names setting other to anything other than 1, which is the default.
0 => You should not set lower_case_table_names to 0 if you are running MySQL on a system where the data directory resides on a case-insensitive file system (such as on Windows or macOS). It is an unsupported combination that could result in a hang condition.
But let's try changing it to 2:
# Specifies the on how table names are stored in the metadata.
# If set to 0, will throw an error on case-insensitive operative systems
# 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.
# NOTE: Modify this value after Server initialization won't take effect.
lower_case_table_names=2
C:\Program Files\MySQL\MySQL Server 8.0\bin>mysqld
--defaults-file="C:\Program Files\MySQL\MySQL Server 8.0\my.ini"
ERROR [MY-011087] [Server, Different lower_case_table_names settings for server ('2') and data dictionary ('1').
ERROR [MY-010020] [Server, Data Dictionary initialization failed.
After initialization, it is not allowed to change this setting.
So lower_case_table_names needs to be set together with --initialize.
It is prohibited to start the server with a lower_case_table_names setting that is different from the setting used when the server was initialized. The restriction is necessary because collations used by various data dictionary table fields are based on the setting defined when the server is initialized, and restarting the server with a different setting would introduce inconsistencies with respect to how identifiers are ordered and compared.
mysqld --initialize --console --lower_case_table_names=2
Then you will get following error in workbench after initilizing the server again with lower_case_table_names=2:
A server configuration problem was detected. The server is in a system that does not properly support the selected lower_case_table_names option value. Some problems may occur.
show variables like lower_case_table_names;
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| lower_case_table_names | 2 |
So conclusion: on Windows leave the setting to 1 because 0 or 2 won't work or as they put it: some problems may occur.
I do however now have my database and table names showing up with Capital letters.
Which doesnt really do much because comparison will always be :
# 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.
Nicholas
If your data files are on a drive different than the C: drive, you may actually have 2 "my.ini" files, one will be on the C: drive and when you edit the Options in Workbench, that is the file that gets changed while the "My.ini" your system is actually working from is left alone.
Check C:\Program Data\MySQL\MySQL(server version), to see if there is an .ini file there. If so, you will probably find it has the changes at the bottom of the file that need to be written to the actual working .ini on the drive your data is really stored on.
In workbench go to : management panel > Options File > General > System >
Check the "lower_case_table_names", put value 2.
Close Workbench.
Restart Service MYSQL56
See img here How to enable
Edit this file at /etc/mysql/my.cnf
Add following lines:
[mysqld]
lower_case_table_names=1
Restart mysql sudo /etc/init.d/mysql restart
In an article about securing MySQL they recommended disabling LOCAL INFILE unless I need it.
http://www.greensql.com/content/mysql-security-best-practices-hardening-mysql-tips
I would like to do the same in MariaDB but the following config line doesn't seem to work in MariaDB (used to work in Mysql):
set-variable=local-infile=0
Does anybody know how to disable it? Or maybe it doesn't have a runtime config switch and needs to be compiled with a specific configure flag?
The set-variable method of setting variables was deprecated in MySQL 5, and instead you can set the variable by name directly in my.cnf.
This works for me in MariaDB 5.5.34:
[mysqld]
local-infile=0
MariaDB's documentation on setting server variables recommends setting values in my.cnf using the format
variable-name = "value"
I am storing images in MYSQL.
I have table as
CREATE TABLE myTable (id INT, myImage BLOB);
When I am trying to insert 4.7MB file, I am getting exception as
com.mysql.jdbc.PacketTooBigException: Packet for query is too large (4996552 > 1048576). You can change this value on the server by setting the max_allowed_packet' variable.
I believe this is related to image size only. Is there any other variable type that I can use?
Update 1
As per older SO question, I also tried with MEDIUMBLOB but still I am getting same error.
Adding Image to a database in Java
Update 2
At the start of the project, I execute below query and everything is working now
SET GLOBAL max_allowed_packet = 1024*1024*14;
As the error says, it has nothing to do with variable type but rather the max_allowed_packet variable:
You must increase this value if you are using large BLOB columns or long strings. It should be as big as the largest BLOB you want to use. The protocol limit for max_allowed_packet is 1GB. The value should be a multiple of 1024; nonmultiples are rounded down to the nearest multiple.
But, generally speaking, don't store files in your database - store them in your filesystem and record the path to the file in the database.
For Windows users:
mysql_home points to your mysql/mariadb installation folder.
open cmd, cd to %mysql_home%\bin and run mysqladmin > temp.txt This will spit out a lot of information about the usage of the tool. Somewhere among all that output you will find this information:
Default options are read from the following files in the given order:
C:\windows\my.ini C:\windows\my.cnf C:\my.ini C:\my.cnf c:\mariadb-5.5.29-w
inx64\my.ini c:\mariadb-5.5.29-winx64\my.cnf
This shows that you could have, if you don't have it already, a file called my.ini or my.conf in the %mysql_home% directory.
create my.ini and add the lines:
[mysqld]
#allow larger BLOBs to be stored
max_allowed_packet = 10M
make sure to include the settings group which is [mysqld] otherwise it will fail to start (and for me it ended up hanging in limbo).
You will now need to restart the MySQL daemon, this is done either by killing and starting the currently running mysqld process or by restarting the MySQL service (run services.msc, locate MySQL, press the restart button; or from cmd, net stop MySQL followed by net start MySQL).
Following worked for me
edit my.cnf file ( mine was in /etc/mysql )
Then modify the max_allowed_packet value
I set it to
max_allowed_packet=200M
Make sure you restart MySQL for change to take effect
If working with AWS RDS, max_allowed_packet can be modified using DB Parameter Groups
The max_allowed_packet variable has a default value set in the configuration file (my.ini in my case). If your application tries to execute a query whose packet size exceeds this value, this exception is thrown.
My setup is on a Windows 10 machine with MySQL Server 8.0.
I copied the my.ini file with my desired value (64M) for max_allowed_packet to the various possible locations (C:\my.ini, C:\Windows\my.ini). Then restarted the mysql server. It didn't work. When I queried the database for the max_allowed_packet variable, the value remained unchanged.
The following steps worked:
I discovered that there is a my.ini file at a different location.
Open the my.ini file at the following location C:\ProgramData\MySQL\MySQL Server 8.0. This has lots of entries, besides max_allowed_packet.
Locate the entry for max_allowed_packet, and set it to the desired value (for e.g. 64M).
Save and close the my.ini file.
Restart the MySQL80 service.
Log into to the mysql server prompt and run the query
show variables like 'max_allowed_packet';
You should see the value set to your desired value.