I want to add 'On delete cascade and on update restrict' on foreign keys through phpmyadmin user Interface instead of executing query.
I generally use Heidisql control panel for doing these actions. And now I'm having hard time doing the same on phpmyadmin.
Any idea?
In the tab where you define the table structure, you get the list of columns and their properties and underneath that there should be a link "relation view", between "print view", and "propose table structure."
That's where you want to go, but you have to have created the index on both tables already.
Also, you might want to make sure you're using mysql's innoDB storage engine.
Edit : An image is worth 1000 words :
Cimbali's answer worked for me, but things were placed a little differently, so in case you're also looking for the "relation view" link, try looking there:
It should take you there:
Key fact:
1. Both table must be have innodb storage engine.
2. The datatype and length should be same in both table.
3. The field in 2nd table should be created as index.
Hope it will help someone...
Related
Update: After a lot of painful research, I've discovered what the problem actually is and updated the title to make a little more sense. I'll put my answer below.
Unfortunately, I'm not able to copy the query that's giving me this problem because it belongs to my company, so I'll have to keep my question very specific.
I have an INSERT INTO ... SELECT query that's returning this error:
Duplicate entry <gobbledygook> for key 'idx_<tablename>'
The tablename at the end is the correct name, but it has this weird idx_ prefix before it that's not a part of any of the tables I'm currently working with. What is that idx? Does it have something to do with the information_schema?
Update: Apparently, I need to clarify something: There is no column with idx in the name.
The numerous websearches didn't reveal much when I was trying to solve this problem, but I did finally figure it out (and JohnH's answer helped me to do this).
I finally discovered that "idx" is not something created by MySQL, but a name that someone else gave to the index. I have never come across a uniqueness constraint on an index that wasn't a key before, so I didn't know where that error came from.
This command showed all of the indices:
SHOW INDEX FROM <tablename>
And I was able to see that non-unique was set to 0 for this key.
To fix the problem, I was able to simply drop the index and recreate it, without adding a uniqueness constraint.
DROP INDEX idx_<tablename> ON <tablename>;
ALTER TABLE <tablename> ADD INDEX idx_<tablename> (<comma-separated columns>);
Whether or not removing the uniqueness constraint is a good idea remains to be seen, but it's also beyond the scope of this question.
"idx_" is a common prefix for index names.
You many have an index that does not allow duplicate values for the column values referenced by that index.
In my case the unique index had duplicate entries even though the column being indexed didn't. I can only think this was caused by a bug. Solution was
Stop the service that writes to the db
Drop the index
Recreate the index
(Do the operation that was previously failing)
Start the service
It's important if you are dropping an recreating an index that nothing can be given an opportunity to insert a duplicate entry while you are doing this. This is why I stopped the service that writes to the db.
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)
Normally I have no issue with MySQL's PHPmyadmin designer to create referential integrity relations.
All of a sudden, I now get a 99% Loading in my browser window, and a popup php.
Reproduce;
Select a database.
Select designer.
Select 'Set Relation'
Select a primary key
Select a coresponding foriegn key
Approve confirmation
Expected results; (and what I usually get)
A relationship is setup.
A line connecting two keys.
Actual results;
a green label "Loading 99%" appears in upper right corner.
a second window pops up http://localhost/phpmyadmin/pmd_general.php?db=jobhunt&server=1&token=d8235.....
Relationship does not occur.
Is anyone else getting this?
Yep, it was happening with me too. I've made some attempts here and discovered that the error of the blank pop-up occurs because I was trying to make a relationship with a foreign key that has no index set up.
Create an index for the future foreign key column and that may resolve.
Pay attention that when you try to make the relation without the index, the confirm box that appears has just a "Ok" and "Cancel" button, while when you already have the index, it permits you to set up the behaviors on delete and on update.
[Solved] Just update Java for Windows plugin for your browser (Firefox, Chrome...)
Go to Java site and update Java Firefox plugin.
One more solution is install and use SQLyog;
While I still do not know why the interface decided to break but an add Forien Key works fine.
ALTER TABLE tableblah
add FOREIGN KEY FCK2-BLAH ([Foreign-Key column]) REFERENCES [primary key table]([primary key column]);
This method works for me:
1. Select table and click on Operations.
2. Change Storage Engine in table option to InnoDB.
3. Hit "Go" button.
Now, you can add foreign key by adding INDEX on column.
Once a record is entered in a particular table, I think I don't ever want it to be deleted. The records are there to keep track of things for historical purposes. I'm using MySQL, InnoDB. Is there any way I can protect that table from accidental deletes by the application layer? If so, is this a good approach?
If you can set the permission for your user(s), don't give the delete permission. There're situations where this practice is a "must be" like the tables for statistics purpose. Thus, if your table is used to achieve one of this goal, it's a good approach.
I use a trigger that detects the deletion and does some illegal stuff so the whole operation fails. For example like this:
CREATE TRIGGER protect_delete before delete ON protected_table
FOR EACH ROW UPDATE non_existing_table SET non_existing_column=1;
So when someone will attempt a delete operation - the whole statement will fail. You also might use better names for non_existing_column and non_existing_table.
E.g it is possible to obtain an error message like this:
ERROR 1146 (42S02): Table 'database.delete_restricted_on_tableX'
doesn't exist
EDIT: also it is possible to create even better fail messages, please check here http://www.brokenbuild.com/blog/2006/08/15/mysql-triggers-how-do-you-abort-an-insert-update-or-delete-with-a-trigger/
One other option is switch to the ARCHIVE engine for historical tables.
This will prevent any DELETE or UPDATE actions on the table, and compress the data. One (major) downside to this approach is that you cannot index the columns on the table.
I think you should implement this logic in your application layer and insert a column where you put a no-delete flag.
Another idea would be to exclude the delete access for the db user
You may want to write a trigger that detects the deletion, then reinserts the record, but there may be some issues with that, so you can also just add a foreign key constraint that will prevent the deletion.
For some discussions on this you can look at: http://rpbouman.blogspot.com/2011/10/mysql-hacks-preventing-deletion-of.html.
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.