The table whose engine needs to be converted is only for read purpose and its content will never change. So I want to convert the engine of the table as ARCHIVE, but when I tried to convert it, I got the error below.
Error Code: 1069. Too many keys specified; max 1 keys allowed
The version of MySQL is 5.5.
Is this index related problem?
Looks like it definitely is a PK problem since archive does not support primary keys. You can simply drop the primary key and it should work.
Refer to this post for examples on how to convert your db
Related
I am trying to run some basic CREATE TABLE statements for my Databases course project and am getting some strange errors.
When I create the table Manuf it runs fine, but when I try to create the next table, Order, using the same syntax, it does not work.
Also, when I try to create this table, Items, I get an errno: 150. I believe this has to do with my foreign key creation, but I am not exactly sure. Here is a screenshot of that.
I am fairly new to using MySQL so any advice would be greatly appreciated, thank you.
The error on the Order table is caused by ORDER being a reserved word. You can specify it as `Order` with the backticks, but it's better if you choose a different name altogether.
The error 150 is related to the foreign key. The keys must be absolutely identical - the exact same definition, or the FK will fail with error 150.
Also, there must be an available index with that key definition or one compatible (see Kai Baku's example in the comment on the MySQL manual page). The same fields indexed in a different order will fail.
To begin with, check how those keys are defined in the origin tables. For example:
test1 varchar(50) not null
test2 varchar(50)
will not be compatible. I think that even a different collation is enough to throw FK off kilter (but this I haven't checked. The rest I'm sure of, from my personal bitter unexperience).
UPDATE: I forgot to mention, if you use InnoDB tables and issue the SHOW ENGINE INNODB STATUS, the blurb that comes out will contain a much better explanation of why the FK failed, somewhere about one third from top.
I have a database that I built a while back. Every table in the database is InnoDb. Several tables had foreign key constraints, and I set them up for On Delete = Cascade. When I was using an earlier version of phpmyadmin, working with these was simple: I'd just go to the Structure tab of a table, click the Relation View link, and as long as I had the correct indexes set up on the correct columns, I could set the foreign keys as I saw fit.
Since upgrading to version 4, it's become a nightmare. For some tables, I go to the relation view and everything is just fine. But for others--even when they already have foreign key constraints set--I can't see any options for working with them.
To make matters worse, I've even tried dropping the indexes and re-adding them, only to be given the following error: Cannot drop index [index_name]: needed in a foreign key constraint. So unless I'm mistaken, the constraint is there, but phpmyadmin is refusing to show it to me.
Is there something I have to do to make them show up again? This is extremely frustrating to say the least: something that worked just fine before now does not thanks to an upgrade.
OK, after playing around with the tables a bit, I figured out what's going on. The only time the foreign key constraint options don't show up are when the table names contain capital letters. Very frustrating to say the least.
I just filed a bug report for phpmyadmin: https://github.com/phpmyadmin/phpmyadmin/issues/11461
It should be an easy fix.
happened to me because i used '&" in the database name.
In my case it is that I used two columns (A and B) both as foreigns keys to other tables then I also used a composite unique for ([A, B]), phpMyAdmin does not show the existed foreign index of column A but does show that for column B.
My system version are as follows:
Server version: 5.7.30 - MySQL Community Server (GPL)
I'm writing some code to inspect a MySQL database structure, and need information about Foreign Key constraints (on InnoDB tables).
There are two ways I know of to do this:
Parse the results of SHOW CREATE TABLE X
Use INFORMATION_SCEMA.REFERENTIAL_CONSTRAINTS
Unfortunately option two requires MySQL 5.1.16 or later, so I can't use it unless/until I can convince our server guy to update, And while I can probably get away with option 1, it feels messy and without writing a full SQL parser I wouldn't feel sure my code would always work with any table.
Is there another way of getting at this information?
Thanks
From the MySQL 5.0 manual online:
You can also display the foreign key constraints for a table like
this:
SHOW TABLE STATUS FROM db_name LIKE 'tbl_name';
The foreign key constraints are listed in the Comment column of the
output.
Poster indicates that this doesn't provide ON UPDATE and ON DELETE information which is an important part of foreign key behavior.
Another option:
Since you control the code involved, is it possible to set up another MySQL instance in the same environment which is version 5.1+? If so, let's call that instance dummy. Run the SHOW CREATE TABLE on the live database. Then, on dummy run a DROP TABLE IF EXIST followed by the output from the SHOW CREATE TABLE query.
Now you can use INFORMATION_SCHEMA on the dummy database to get the information.
I am using Enum data type as a primary key referenced as a Foreign key in another table. If i have to add an extra element to this enum value, I use
ALTER TABLE <table> MODIFY <colName> ENUM(<OLD VALUES>, NEW VAL);
on both the tables. It works fine.
I had one obscure example in which I ended up going from <255 values to more. In that case, ENUM will need to switch from 1 byte storage to two bytes storage. That is when it fails. Giving me
ERROR 1025 (HY000): Error on rename of './TXCAD/#sql-5912_86' to './TXCAD/EN_TABLE' (errno: 150)
I did a some research and found out this conversion from 1 byte to two bytes in the main table makes the foreign key data type discrepancy. (If i start with 256+ values, this doesnt happen at all. I verified that)
Is there a way to force MySql to use 2 bytes from the start even if ENUM() has less than 255 values during table creation?
Using
MySql - 5.1
InnoDB tables
Just so you know, I searched on this for quite a bit. From the docs, it really appears that the only way to get a 2 byte enum at table creation time is the way that you mentioned... that is, specify more than 255 items in your enum list. I don't see another part of table create syntax that allows for it. Your only other hope would be that there is a config file parameter that enables a different default.
A list of server system variables exists, but I did a quick search, and didn't see a reference to one that might change the default behavior for enum field size.
http://dev.mysql.com/doc/refman/5.1/en/server-system-variables.html
(note, this page is very large, and hung my browser momentarily.)
Just thought you'd like to know that someone else looked at the question and decided to investigate further, instead of just listening to crickets...
I have two databases, tvguide and episodes1.
Both are InnoDB, and I use Phpmyadmin to edit them.
I tried creating a foreign key between the "episode" field of episodes1 and tvguide, and this error message came up:
Error creating foreign key (check data types) : episode
How can I fix this and ensure both tables join? I have InnoDB set for both databases, so this shouldn't happen, but why?
It may be that you have defined the 'episodes' column differently in each table. That could cause the operation to fail. Perhaps you could post (possibly trimmed versions of) your table definitions here. Then we can say for certain.