If I have a column names called category_id and Category_Id, are they different?
And if I have table called category and Category, are they different?
On Unix, table names are case sensitive. On Windows, they are not. Fun, isn't it? Kinda like their respective file systems. Do you think it's a coincidence?
In other words, if you are developing on Windows but planning on deploying to a Linux machine, better test your SQL against a Linux-based MySQL too, or be prepared for mysterious "table not found" errors at prod time. VMs are cheap these days.
Field (column) names are case-insensitive regardless.
EDIT: we're talking about the operating system on the MySQL server machine, not client.
From the MySQL documentation:
database and table names are not case sensitive in Windows, and case
sensitive in most varieties of Unix. One notable exception is Mac OS
X, which is Unix-based but uses a default file system type (HFS+) that
is not case sensitive.
and
Column and index names are not case sensitive on any platform, nor are column aliases.
For database and table names, it depends on the underlying operating system.
See 8.2.2. Identifier Case Sensitivity
Strangely enough it seems to be case sensitive in the MySQL Workbench even on Windows.
We just tried to alter the results of a SELECT statement but the Workbench didn't let us, complaining that our query did not include the table's primary key (which it did but in lower-case) so the result was read-only. Running the same query with the primary key in proper case (ID instead of id) would let us edit the results as expected.
Related
I want to name my mysql table column names using camel case and create php classes from these mysql tables with the same camel case names. I will be generating these php classes automatically. I'm wondering if I can rely on column name case no matter what platform I run my application on. So for example, if I name one column name "FirstName", will I ever encounter a time where reading the column name from the database will product "firstname" or something like that?
Short answer is no.
The long answer is that case-sensitivity for some things in MySQL depend on the underlying operating system. (Unix being the sensitive one)
Here is the reference to the issue in the MySQL documentation.
Consequently, the case sensitivity of the underlying operating system plays a part in the case sensitivity of database and table names. This means database and table names are not case sensitive in Windows, and case sensitive in most varieties of Unix. One notable exception is Mac OS X, which is Unix-based but uses a default file system type (HFS+) that is not case sensitive.
Also from the documentation on column names specifically:
Column, index, and stored routine names are not case sensitive on any platform, nor are column aliases. Trigger names are case sensitive, which differs from standard SQL.
MySQL is case sensitive in table and column names, and case in-sensitive in keywords.
But note that Windows is only case preserving, and file names are table names. (If you work on table "SalesAccounts" when you meant "Salesaccounts" then it will read OK on Windows and fail on Linux.
You should be OK with what you want to do, but
1) Test on Linux,
2) Test the tools you are using.
I'm currently moving my project to production and found an odd situation. The database was (unfortunately) created with object names in lowercase. Now, I'm acting on table all over my 100+ stored procedures/functions, not always keeping in mind the fact that I should use lowercase for table names.
I made a simple test:
select * from mytable ;
yields all the records in the table, whereas:
select * from Mytable ;
returns a "table does not exist" error.
Is there any solution someone could suggest besides going one by one through each and every stored procedure/function and correct the case of the table names?
Thanking in advance for any life-saving suggestion.
From the MySQL documentation on cases in identifiers:
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.
I would probably take the time to make everything lower case because it will save you headaches further down the line. If you have a client with a decent editor like MySQL Workbench then you can do these replaces with a quick find and replace.
EDIT:
According to the documentation, you can try setting the lower_case_table_names system variable to 1, which will:
Table names are stored in lowercase on disk and name comparisons are
not case sensitive. MySQL converts all table names to lowercase on
storage and lookup. This behavior also applies to database names and
table aliases.
This might solve your problem if all of the table had been created with lowercase on disk.
In Linux server I am Configure Apache and PhpMyadmin.
In the database my table's name is mst_vehicle
when I fire a query like select * from mst_vehicle it will give right result, but
When I fire a query like select * from Mst_Vehicle It will give an error.
Please help me how to resolve this problem.
I import the database from windows to linux phpmyadmin and my windows database is already with lower case table name.
Database and table names are not case sensitive in Windows, and case sensitive in most varieties of Unix.
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). Consequently, the case sensitivity of the
underlying operating system plays a part in the case sensitivity of
database and table names. This means database and table names are not
case sensitive in Windows, and case sensitive in most varieties of
Unix. One notable exception is Mac OS X, which is Unix-based but uses
a default file system type (HFS+) that is not case sensitive.
Have a look at Identifier Case Sensitivity.
You can get the correct case-sensitive table name from case-ignorant name by doing this:
select table_name from information_schema.tables where lower(table_name)="mst_vehicle" and table_schema="YourDatabaseName"
It will however add a performance penalty.
I have this mysql db, it has duplicate table names, just different lettercase. So when importing these tables to my windows xampp setup through phpmyadmin, mysql just ignores the imports with same table names. So I have these tables:
dealer
Dealer
I import dealer just fine, then when I import Dealer, mysql says table exists, and ignores the Dealer import all together.
When starting mysql, you must set the system variable lower_case_table_names to 0.
On linux, , which uses a case-sensitive file system, you can do it.
On Windows, which uses a case-insensitive file system, you can not do it, because windows can not distinguish between the two cases.
See this documentation for details.
I am working with a MySQL database that has capitalized table/field names like Users, Institutions, etc. Because the operating system of the database host is Linux, identifiers (like the table names) are treated as case sensitive. So, failing to capitalize a table name will result in a table does not exist error.
The problem I am trying to solve is that ActiveRecord always constructs identifiers in lower case. So, for example, if use the "find" method to grab the first record from the Institution table, the resulting SQL will look like:
SELECT `institutions`.* FROM `institutions` LIMIT 1
This, of course, results in a MySQL error in a Linux environment because it is not case sensitive.
Any thoughts on how one might get around this issue?
Thanks in advance!
class Mouse < ActiveRecord::Base
set_table_name "Meece"
end
Should clear you right up I think.
Rails use convention over configuration to determine the name of the table from a model.
But you can always tweak the default to match your legacy databases.
Have a look here:
http://book.opensourceproject.org.cn/lamp/ruby/railscook/opensource/0596527314/i_0596527314_chp_3_sect_20.html
and here:
http://railsapi.com/doc/rails-v3.0.0/classes/ActiveRecord/Base.html#M001129