I have a table name that starts with an underscore does that give any special status to the table?
I am asking because the table does not seem to be taken by the replication in some instances. In the MySQL Query Browser it is also impossible to use the "Edit" feature on that table but it is on all the other tables.
We are using MySQL 5.0.37
Cheers,
No, it does nothing special ^^
Related
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.
So I don't want this thread to be marked as spam, as a previous thread was on this topic was, so I will explain what I have done so far and my issue is and ask if there are any solutions.
I have a MySQL database on my laptop that I need to migrate to DB2 on iSeries. I'm using a tool, I won't say which one because of the spam issue, which allows me to "copy" a table in my MySQL database and "paste" it into my DB2 database.
The issue that I'm having is because the table names and column names contain spaces in the MySQL db, the tool is failing on the paste. I confirmed this by altering one table by replacing the spaces with underscores and the copy worked perfectly. I have over a hundred tables I need to copy over and don't want to have to manually edit every table and column name.
Is there a way to globally replace spaces with underscores in MySQL table names and columns?
Any other ideas? I'm also researching a way to force the query the tool creates to enclose the object names in quotes, but have had no luck so far.
Thanks for any help and suggestions you can provide.
Since Stack Overflow is about helping to solve programming problems, I'm going to ignore the issue of deficiencies in the chosen tool and propose a programming solution to the larger problem - DB2 does not allow spaces in table and column names. You did ask for any suggestions...
Write code that reads the MySQL catalog tables. In DB2 they'd be SYSTABLES, SYSVIEWS, SYSINDEXES, SYSCOLUMNS, etc. Read SYSTABLES and use that as the 'primary' source for the rest of the code. Check the table name; if it has an embedded space, replace it with an underscore. Use SYSCOLUMNS to generate a CREATE TABLE statement that will create the new table (in a new MySQL database?) - also performing space to underscore replacement. After issuing the CREATE TABLE, generate an SQL statement that will INSERT INTO the new table the columns from the old table; again doing the space to underscore substitutions. Once the new table is populated, generate SQL statements to CREATE VIEW, CREATE PROCEDURE, CREATE FUNCTION, etc.
The general idea is that you will completely re-create your MySQL database with table, view and column names that are immediately compatible with DB2 for i so that your tool can do it's thing.
Of course, if you go to that much trouble it'll probably be just as easy to directly CREATE TABLE, etc on the IBM i side rather than go through an intermediate tool that isn't quite what you need.
I have a DB called:
MY_XXXX and MY_YYYY.
When I go to the phpMyAdmin, it shows in the tree structure...like this:
So, my questions is, is the MySQL or the phpMyAdmin do this things for me...? Is this have some special meaning for that? Thank you.
This is phpMyAdmin making a (sort of reasonable-ish, a bit, actually largely un-warranted) assumption about a naming convention - it's nothing to do with MySQL.
If your looking for more information on such things - see the MySQL Schema Object Names documentation. (As you'll see - it defines no special meaning to the underscore other than stating that it's considered a valid character.)
THis means you have multiple databases starting with MY .
So rather then showing showing it in different headings as MY_1, MY_2 phpMyAdmin shows them as
MY_
1
2
etc.
I'm wondering if a database name can start with a number e.g 143doors.
I found some answer here http://markmail.org/message/yw57rt3tweldtxet but I'm not quite sure since it's 1999.
Will there be disadvantages if I start with a number?
Within MySQL Workbench, you are going to have trouble querying if you do something like {db_name}.{table} and your db_name starts with a number.
The solution to this is the backtick mentioned in the accepted answer. An example is like:
select * from `2013e93`.blurb
where the db_name is 2013e93 and the table is blurb.
A quick test says, yes you can. Using spaces in database names will lead to trouble, though. You'll have to use `143 doors` (with the backtick) if you really want to do this.
Does MySQL allows to create database which has dot (.) in its name?
I'm using MySQL 5.1.22.
You can't use the dot in a database name. Also, I'd avoid using it in any identifier. A common convention is to use underscore instead. It will serve the same purpose and will avoid a LOT of confusion. If you do have a good reason for using strange and otherwise-illegal characters in a table or field name, then you have to escape it.
to escape identifiers in MySQL, use the backtick:
SELECT `select`, `some.field name`, `crazy()naming+here`
FROM `my-=+table`
Getting into the habit of backticking all field names regardless of whether you need to is a good practice in my opinion, but that's another story.
You can use . in names from MySQL 5.1.6 according to the documentation.
However, as has been said and will said again, please don't do it. For every problem you think you're solving now you'll be creating five which will bite you later on. Since . is used to qualify names - e.g. database.table or table.column you'll have to quote your database name every time you use it.*
You can do this with backticks:
CREATE TABLE `do.not.do.this` (col INT);
or using double quotes if you set the following option:
SET sql_mode='ANSI_QUOTES';
CREATE TABLE "asking.for.problems" (col INT);
* Not strictly true - you have to quote any character that's not alphanumeric or _ or $ , but . is a particularly troublesome option to have in your names.
Before MySQL 5.1.6, database and table names cannot contain /, \, ., or characters that are not allowed in file names (see 8.2. Schema Object Names).
In versions after 5.1.6 you have to quote your tablename with a backtick (`) - but as others also advised: you shouldn't do this to prevent any unnecessary trouble.
MySQL 5.0.22 doesn't appear to allow it:
% mysqladmin -uroot -pXXX create foo.bar
mysqladmin: CREATE DATABASE failed; error: 'Incorrect database name 'foo.bar''
Even it if it did allow it, I would strongly recommend against it.
At the very least you'd have to escape any reference to that database with backticks in every single query that ever uses it.