Can I replace a table in DB through phpmyadmin. Table has two foreign keys and I can truncate it by disabling foreign key checks (or delete it completely), however when I try to reupload it, if I don't enable foreign key checks it doesn't connect to the tables it should (I can't click on foreign ID, usually it takes me to the related table). If I do enable foreign key checks I get an error
#1452 - Cannot add or update a child row: a foreign key constraint fails
Is there a way to somehow replace a table with the same table from the past by keeping the relations alive?
i think the table contains data ... try clearing the table before dropping it.
Actually "you don't need to disable foreign key checks" if you want to delete from (or truncate) only the table(s) where child records are stored. You should be able to delete all and re-insert them later. Please try it this way.
You need to disable the foreign key checks if you want to truncate the tables with primary keys without deleting the child records. (This is not reasonable though.)
The following steps in order should work fine without disabling any constraint. If you don't follow the order, it will fail. You can skip the steps 2 and 3 and use 1 and 4 only.
Delete all child records with foreign key pointing to a primary key.
Delete all master records with primary key.
Re-insert all master records with primary key.
Re-insert all child records with foreign key pointing to a primary key.
Anyway, the error you get sounds like when you try to insert the old data, the matching record is missing in the master table where the foreign key points to.
You can check:
Whether the data in the master tables (the tables with primary key where foreign keys point to) are also deleted or truncated. If so, you need to bring them back before the child records.
Whether the data in the master tables are not the same anymore and the consistency is lost with the old data. (If you are working on a production database, the data might be changing). If so, you need you need to bring the missing records back to the master table.
Related
I have watched several tutorials on setting up foreign key constraints on phpMyAdmin now, but I can never seem to make it work.
My aim is to store names in the names table, then have those names as the foreign key of the stats table, where the stats linked with each player will be stored.
The stats table (with index)
(The name table is indexed in the same way as the stats, using the index button)
The setup of the foreign key constraint
No connection seems to have been properly made, since attempting to display the values of statname in PHP yields nothing.
I realise that it's important for the concerning fields to have IDs, which I have created, and in the version of phpMyAdmin I have (4.5.1), ID names don't seem to be displayed in the foreign key constraints section, only the fields those IDs refer to.
I'm pretty new to this, any help and advice would be welcome.
In the player names table, make a field (player_id) which stores the unique id of each player as the primary key which will uniquely identify the player from the table.
Next, in your stats table, take a field (player_id) amd make it as a foreign key which will reference the (player_id) field from the player table to refer the player stats in the stats table.
When i need to set a field as the foreign key in a table,in PHPMyAdmin. I am not getting it set right.
There is a Parent table called 'user' which has a primary key called 'uid'.I am using the 'uid' in the child table called 'student_register' as foreign key. But while setting it as foreign key constraint through the relation view link in phpmyadmin . i am not able to see the 'user' table in the drop down list to select it and set the 'uid' as foreign key .. I have sent the screen shot to get a clear picture.
the screenshot for the phpmyadmin child table 'student_register'
From the MYSQL User Guide:
If you are facing this issue than you need to follow these basic steps:
Database storage engine must be InnoDB.
Your relational tables must be InnoDB.
Use UNIQUE reference key.
Reference Key can not be NULL.
Datatype of the both columns must be same.
References:
Create Table Foreign Keys in MYSQL
Creating Foreign Key Relationships
You should add index to the column uid in table user in order to appear in the drop down list
Take the structure of table user, then click the last option of the Action - Add index for the column uid.
I have a running database on customer's server, and production database on my PC. As usual, production DB is updated as I develop with new fields and records.
I need the entire production DB (including estructure and records) to be replaced with customer's server existing DB.
When I export production DB and try to import on cutomer's server, I get
Duplicate entry '1' for key 'PRIMARY'
This is expected: If there's an existing primary 1 ID, it is normal that PHPmyAdmin avoids me replacing it. So I try to TRUNCATE or DROP this table, in order to re-import it fully again. When I try to do this, this (also expected) error emerges, avoiding me to remove FK fields:
#1701 - Cannot truncate a table referenced in a foreign key
constraint (`waisap_db`.`ws_stdmessages`, CONSTRAINT
`ws_stdmessages_ibfk_1` FOREIGN KEY (`sm_fk_us_id`) REFERENCES
`waisap_db`.`ws_users` (`us_id`))
How could I update entire DB? Which option whould I choose when exporting development DB?
You can SET FOREIGN_KEY_CHECKS = 0; before importing and then set it back to 1 after to avoid foreign key constraints error.
I have a table 'release_group' and another table 'release', like so:
release_group
------------------------
release_group_id (PRIMARY KEY)
name
main_release_id (FOREIGN KEY)
release
------------------------
release_id (PRIMARY KEY)
release_group_id (FOREIGN KEY)
name
If i create a release row, the release_group_id is not available, simply because it hasn't been created yet. But i can't create a release_group row without the main_release_id. So it's kind of a no way situation.
EDIT:
The main_release_id in release_group is to say that the release is the main from the group, the one i will use a reference.
What is the professional way of handling this case?
1.
Remove the foreign key index main_release_id in table release_group and give an attribute ALLOW NULL. Create the release_group row so i can applied it's id in the release row.
2.
Keep the 'main_release_id' foreign key index in table 'release_group' and assign it a temporary integer value of 0. Create the release row and update the foreign key in the release_group accordingly? Keep in mind that if this is the way to go, i could end up inadvertently having foreign keys with value 0, which i don't know if this ethic in a database?
What is the professional way of handling this case?
Thanks
Seeing how a release cannot belong to more than one group, you could remove the complication by:
Dropping the main_release_id field altogether
Add a release_main field to the release table; it would be NULL (not main) or 1 (main).
Add a UNIQUE constraint on (release_group_id, release_main) to make sure there can only be one main release.
Update
If a release can belong to multiple groups, you would need to create a many-to-many table and move the foreign key in both tables into it:
(release_group_id [FK], release_id [FK], is_main)
The primary key would span the first two fields. Ensuring that there can only be one main release requires a spanning unique key over the first and last field.
Old answer
Assuming main_release_id is a nullable field, what I would suggest is the following:
Insert the release_group with main_release_id being null; get last inserted id.
Insert the release entry, passing the id of the previous step; get last inserted id.
Update the release_group table entry, setting the value of main_release_id to the value you got from the previous step.
Commit transaction
Alternatively, you could use sequences so that you know the id before inserting the entries. See an example of this in the manual under LAST_INSERT_ID().
Looks like you are trying to create a many to many relationship. To do this properly, remove the foreign keys from both the release_group and release tables. Add a new table (release_to_release_group) that contains the release_id foreign key and the release foreign key.
Edit: There is no need for cyclic foreign keys here. Remove the main_release_id foreign_key from release_group and add a is_main_release flag to the release table.
It's not usual practice to have the tables reference each other like that. Usually you would have the Parent table (release_group) as a foreign key reference in the child table (release), but not have the release_id as a foreign key in the release_group table.
Maybe add a boolean flag to the release table to indicate it is the Main release and do away with the main_release_id in release_group.
This is for a sort of proof of concept draft to get things working, but don't want to have completely crap code. For my database, I tried to get true foreign key relations going using innoDB, but couldn't get it.
Instead of using foreign keys, I decided to just pull mysql_insert_id() after inserts, saving it as a variable, then putting that variable into the related table.
Is this horrible? Everything seems to work well, and I'm able to connect and relate ID's as needed. What benefits would using foreign keys give me over my method (besides updates/deletes cascading)?
To create a relation (master->detail), you have to always supply the keys by yourself, either using mysql_insert_id, natural keys or key generated by your applications. The FOREIGN KEY is not going to make that work for you.
What FOREIGN KEY does is
Helping you enforce the relationship/the integrity of your data (so the "detail" record does not point to an invalid parent)
Handles deletion or key alterations of master records (ON DELETE ..., ON UPDATE ...).
It's also creating an index in your "detail"-table for the "master_id"-row if it doesn't exist yet (okay, you could also do that without FOREIGN KEY)
Has also some kind of documenting purpose for example an ERM-tool could reengineer the relationship model from your schema (okay, this point is a slight long shot)
The cost of adding the FOREIGN KEY constraint statement is small compared to its benefits.