I set my tables to InnoDB and can enter the relation view. But I only can add constraints no relations. What causes the problem?
Server version: 5.7.14 - MySQL Community Server (GPL)
phpMyAdmin Version: 4.6.4
WampServer Version: 3.0.6
Here a picture how I expect the view to be, the table "Internal relations" is missing:
Q: "I only can add constraints no relations. What causes the problem?"
A: I don't see any problematic behavior is being reported.
I see a description of the steps you've taken, and I'm guessing that the results of those steps aren't meeting your expectations.
If you could clarify what you expect, we might be able to help.
Briefly...
With InnoDB, a "relationship" between two tables can be expressed and enforced by creating a FOREIGN KEY constraint.
In relational database theory, a "relation" is a set of tuples. In an RDBMS, a "relation" is implemented as a TABLE.
If there was description of what you are attempting to achieve, and a more precise description of the problematic behavior you are observing, it would be possible to give some assistance.
EDIT
With InnoDB, we can use foreign keys defined in the database to represent the relationships between tables. Those are stored in InnoDB table definitions.
The PHPMyAdmin "internal relations" is used for MyISAM tables, which don't support foreign keys.
Verify that PHPMyAdmin is configured to store the "internal relations". It stores the configuration in a table named pma__relation. The actual table name is specified in the configuration of PHPMyAdmin.
https://docs.phpmyadmin.net/en/latest/config.html
If that feature is enabled, there should be a line like this in the configuration file:
$cfg['Servers'][$i]['relation'] = 'pma__relation';
(Consult the documentation for the version of PHPMyAdmin you are running.)
And verify that the pma__relation table exists in your database.
If everything looks to be configured correctly, then I would test the feature with a couple of test tables which use ENGINE=MYISAM, and see if it's working for those tables.
I don't know whether that feature is supposed to work for tables with storage engines other than MYISAM. I don't know if it works with ENGINE=INNODB tables.
Related
i want to know if it's possible to drop a table fragment that is not letting me perform a restore with the NDB_RESTORE tool.
When i run the restore, it throws the following error:
Create table db_died_maestro/def/NDB$FKM_3194_0_mae_tipo_reg_evaluacion failed: 721: Schema object with given name already exists
Restore: Failed to restore table: db_died_maestro/def/NDB$FKM_3194_0_mae_tipo_reg_evaluacion ... Exiting
NDBT_ProgramExit: 1 - Failed
I have already drop the DB_DIED_MAESTRO database previous to run the restore, but this fragment is not being dropped along with the database.
I have check that the fragment is in the database catalog using this querys:
*select * from ndbinfo.operations_per_fragment
where fq_name like 'db_died_maestro%'*
query result
And this query:
*select * from ndbinfo.memory_per_fragment
where fq_name like '%FKM_3194_0_mae_tipo_reg_evaluacion'*
query 2 result
This fragment was created on a previous run of the NDB_RESTORE tool. Please help me.
The table is a foreign key 'mock' table (indicated by the name NDB$FKM prefix).
Foreign key mock tables are created transiently in some cases to implement the foreign_key_checks = 0 feature of MySQL. This feature requires storage engines to support unordered creation of tables with partially defined foreign key constraints which can be abritrarily enabled (without revalidation) at a later time.
Foreign key mock tables are normally entirely managed by the Ndb storage engine component of MySQL, and so should not be visible unless there has been a failure or bug of some kind.
If you can share information about activities occurring before this problem then that would help us understand how this happened and whether it can be avoided.
As a workaround it should be possible for you to use the ndb_drop_table utility to drop this table, before re-attempting the failing restore. You may have to escape the $ in the name passed as a command line argument from a shell. Probably you should check for any other NDB$FKM tables in a similar situation.
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 have recently switched jobs and at this new company we are using MySQL. I don't have any expereince with MySQL, although I have used SQL Server and Oracle for over 4 years now.
Now the strange thing I see with MySQL is that it does not seem to resepect some of the basic things like Foreign Key Constraints (meaning a column is a foregin key but i can insert any value here no matter if it's present in the other table where this FK related to). Now I know in SQL Server there is this concept of a NOCHECK foriegn key constraint but the guy at new company responsible for MySQL db say that not respecting a FK is a normal thing in MySQL and it does not need to have any special settings (like NOCHECK FK constraint).
I fail to understand that in a database system how can you ensure referential integirty without having these basic checks in place. I am not sure if the local mySQL "expert" know it well or it's just that mySQL really does not respect FK rules. Any thoughts?
Check that your tables are using the InnoDB engine. When using the MyISAM engine (which was the default until recently), foreign keys declarations are not enforced.
MySQL have different DB Engines -
MyISAM - default, no FK support
InnoDB - have FK support - but no fulltext search like in MyISAM
On both engines you can create table and try to create FK, but MyISAM will simply ignore it.
Also, make sure foreign keys are being enforced. For some reason they weren't on mine, leading to one week of headache!
Check:
SELECT ##FOREIGN_KEY_CHECKS
Set:
SET FOREIGN_KEY_CHECKS=1
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.