I'm in a bit of a jam. I have this table with a few of relationships, one of which was referencing itself (let's call this relationship A).
I needed to delete some rows from this table but because one of my relationships was referencing itself I was unable to do so. Therefore, I simply deleted relationship A and saved the table.
After deleting the rows that I wanted to delete, I attempted to re-add relationship A, however I am now presented with the following error message.
'T_FormulaireQuestion' table
Unable to create relationship 'FK_T_FormulaireQuestion_T_FormulaireQuestion'.
The ALTER TABLE statement conflicted with the FOREIGN KEY SAME TABLE constraint "FK_T_FormulaireQuestion_T_FormulaireQuestion". The conflict occurred in database "VilleG", table "dbo.T_FormulaireQuestion", column 'intFormulaireQuestionID'.
I believe what this message is saying is that my relationship B is causing a conflict when trying to re-add relationship A.
My question is, how can I re-add relationship A? Do I have to delete relationship B, re-add relationship A and finally re-add relationship B?
I'd prefer not have to delete the entire table as I have important data within it.
Please use the following image as a reference.
Thank you!
You could not delete rows because that would have violated the relationship. After forcing the delete to run, the relationship is, of course, violated... You have destroyed data integrity. Your delete operation was invalid. You silenced the error message but you still executed the error.
Fix the data before adding the constraint back. Probably, this means deleting any rows that are dependent on the now deleted rows in T_FormulaireQuestion. You have to figure out which rows have no matching row in T_FormulaireQuestion and delete them.
You can add the constraint back once it is no longer violated. Note that any violation of the constraint implies that your data is invalid. You should fix this state.
Related
I have a fairly simple design, as follows:
What I want to achieve in my grouping_individual_history is marked in red:
when a session is deleted, I want to cascade delete the grouping_history....
when a grouping is deleted, I just want the child field to be nullified
It seems that MSSQL will not allow me to have more than one FK that does something else than no action ... It'll complain with:
Introducing FOREIGN KEY constraint 'FK_grouping_individual_history_grouping' on table 'grouping_individual_history' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
I've already read this post (https://www.mssqltips.com/sqlservertip/2733/solving-the-sql-server-multiple-cascade-path-issue-with-a-trigger/), although it's not quite the same scenario it seems to me.
I've tried doing a INSTEAD OF DELETE trigger on my grouping table, but it wont accept it, because in turn, my grouping table has another FK (fkSessionID) that does a cascade delete... So, the fix would be to change it all, in all affected tables with FKs. The chain is long though, and we cannot consider it.
For one thing, can someone explain to me why SQL Server is giving me the issue for this very simple scenario in the first place? I just don't understand it.
Is there another workaround I could use (besides just removing the foreign key link from my grouping_individual_history table)?
I need to delete records from relational database, where I attempt to start from the lowest children in the database.
I'm not very strong on how to approach the task. I don't want to do CASCADE delete, I actually want to do the opposite of CASCADE.
Is is correct that I have to find the entity that does not have child and start deleting the records there? and what if an entity has more that one foreign key, how do I decide on which parent table should I start to delete from?
You have to delete the child records first. If you try to delete a record that is referenced with a foreign key, you will get an error which should indicate which key has a conflict. You can then see which child table is impacted and delete the records that are referencing the foreign key, then try again.
You simply work your way up the chain. If more than one child record references a parent record, you simply delete all the child records first. If more than one parent record is referenced by a child record, it doesn't matter which parent is deleted first (or if they are deleted at all).
You don't give what database and what tools you have at hand.
You could manually diagram the database based on foreign keys or you could use a tool, such as visual studios to diagram your database.
As long as the multiple foreign relationships don't depend on one another it shouldn't matter where you start.
I do have a sql table where Table B has a one-to-many foreign key relationship with table A id. I do not want the table B records to be deleted if table A relative parent record is deleted. I have tried CASCADE and NO ACTION at delete & update but nothing gives a solution other than removing the foreign key constraint. Is there another way I can have a work around without removing the constraint?
I didn't hear of any way to have a foreign key constraint and keep the record on the child table after it was deleted from the parent table. Thats why its called constraint, its a rule that cannot be broken.
I can suggest another thing, instead of deleting the record, make it unavailable. Add a date field or an indication feild, that will tell you this record is out of order.
I am working with entity framework.
I have table A & B in 1:n.
Say I delete many rows in A and one of the a key-row in table A has one or many rows in table B.
I get sqlException with the following text
The DELETE statement conflicted with the REFERENCE constraint "FK_A_B".
The conflict occurred in database "DCDCommunity", table "Template.Template",
column 'ApplicationTypeID'. The statement has been terminated.
Is there a way to get the id of the key that violated the Foreign key.
Important EDIT:
I know I can check if B has rows.
But that will be prone to persistency problems.
(Lets say that another insert request is issued right after the check. )
By not checking and letting the database throw an exception I let him deal with the persistency (especially when running on several machines)
Now - If I only had more data in the SQL exception I could rely on this mechanism only.
You cannot delete Rows from A (your primary key table) where there are related records in B (foreign table). That violates the relationship. Therefore you need to first delete them from B and then delete from A. Or you can do ON DELETE CASCADE. Pls Check out this example here
So I have a SQL relationship problem. Lets say I have a database where I want to keep records of information about individuals. Now I have setup a table to take on that information. Okay so far so good.
Often times duplicate information can be discovered in the table and it would be removed. A record is considered a duplicate if a particular field has the same value as another field in another row. Example: Duplicate emails.
Now I want to create another table in the database to keep track of every duplicate that is ever discovered and deleted. My first thought into this was to create a Foreign Key relationship. So I created and then connected a dupes table to my persons table. The relationship was a simple Foreign to Primary key relationship with an on delete constraint.
Now while that may have worked at first the problem arose that the dupes table was receiving records that were deleted even if they were not deleted because they were dupes. This was a problem because even if I decided to delete a person from the persons table just because I did not like them, they would stored in the dupes table anyway.
Then I thought, why not create a disposition field in the persons table and connect that as a unique or primary key to my dupes table's index foreign key. Well the problem is a unique key must have a unique value so multiple dispositions of dupe or I don't like you would not work. The other option was to make the disposition field a primary key. That has the same problem though.
What would be the right relationship for this problem?
I can think of this implementation: An on delete trigger, with a 'before delete' check. The before delete check would confirm if the record being deleted is a duplicate or not. Not sure what all RDBMS systems support such checks though.
IMO, the theoritical relationship is complicated because the record is supposed to be preserved even after the dupe is deleted.
Foreign Keys are not going to solve this problem. I discovered Triggers and their exactly what I need.