Let's say I have a Customers table with columns ID and CompanyId.
I need to delete some companies from the DB.
The problem is, the table has a lot of child tables and those tables also has a lot of child tables and so on...
Just to clarify, all the relationships are with constraints.
How can I accomplish that ?
Thanks.
EDIT: Notice that what i'm trying to do is a one time operation.
Whether i will change the constraints or add triggers or anything like that, I'm planning on removing it in the end.
The inbuilt solution to this problem is to set up your FK constraints with ON DELETE CASCADE.
However many people (myself included) are somewhat uneasy about doing this as a mistaken delete will silently propagate through the database.
Here are three ways:
Use a stored procedure to delete child first then up to the parent row in a transation.
I personally wouldn't make it dynamic and would have a specific "DeleteCompany" proc. Your may need a rule that such as "no delete if sales > 100 million" that needs checked
CASCADE DELETEs on your foreign keys
This can be tricky if you have multiple cascade paths, but simple otherwise
INSTEAD OF trigger
An INSTEAD OF trigger is like a stored procedure in operation. Note: You'll get an FK violation before an AFTER trigger fires
Personally, I'd use a stored proc so I have explicit deletes. The effect is the same as cascading FKs but more obvious.
For SQL Server 2008, this is the solution:
Generate Delete Statement From Foreign Key Relationships in SQL 2008?
With this solution, you can easily find the correct sequence of DELETE respecting, in the meantime, the foreign keys' relationships.
If you are interested in this theme, you can read also the ORACLE PL/SQL solution:
How to generate DELETE statements in PL/SQL, based on the tables FK relations?
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 have table1, table2 and table3 with lets say ID as a common column (no referential integrity is defined but its maintained programmatically with Table1 considered to be the Primary) .
I also have another common column EmpSalary in all the three tables. My requirement is to auto update all the three tables with EmpSalary when anyone of the tables is updated. Is there anything in SQL server which allows to add an auto update statement to the other two tables without enforcing cascade rule ?
P.S - I have tried and researched several possible options and am leaning towards triggers now which is not my favorite object to implement. Looking for alternate solutions here to see if I can avoid triggers.
#Lmu92 - client does not want any constraints on the db, so no an option. Triggers is my current solution looking for ideas until end of day
You could either use a trigger or take care of it in your code (e.g. stored procedure).
Or -my preferred solution- add referential integrity (=foreign key constraints) with cascading updates.
But this would require a "master" table holding the EmpSalary values and being the only one that gets updated...
None of the other options worked, so I ended up going with triggers.
I have lots of tables that have foreign keyed to a PersonId column. I need to delete a person from the database.
If I do a simple:
DELETE FROM Persons WHERE PersonId=111
I get an error:
Msg 547, Level 16, State 0, Line 1
The DELETE statement conflicted with the REFERENCE constraint "FK_CIPerson". The conflict occurred in database "adb", table "CI", column 'Person_Id'.
I keep going "down the tree" of dependencies and delete from the roots. This has generally worked, until I got to a certain table where it won't let me delete any further. I believe I have to join 2 tables and delete the rows in BOTH tables that have my PersonId in it.
This join joins the tables in the way I want them to be joined:
SELECT *
FROM Table1
INNER JOIN Table2 ON Table1.anId = Table2.someId
This results in a joined table that has the PersonId (from Table2). I now want to delete all the rows where PersonId=111, so I need a where clause plonked in too.
Thanks in advance!
By definition, SQL DELETE statement only affects one table. If you need to cascade delete, you can simplify things by using #paqogomez suggestion: just specify ON DELETE CASCADE option on the foreign key declaration.
There are at least 3 solutions:
ON CASCADE DELETE
(As answered by Gerardo) If the problem is just foreign key constraints, then you can use this and deleting the person will do all the rest. But this may not always work. As usr said, there are some cases in which foreign keys are complex and mangled a bit.
BEFORE DELETE TRIGGER
You can define a trigger and activate it BEFORE DELETE on the person table. In the trigger you can take care of the deletion of dependent rows from other tables. This is similar to the ON CASCADE DELETE, but you have a little more control over how to perform the deletion... this may solve some of those complex problems.
STORED PROCEDURE
You can define a stored procedure with a person_id parameter. The code would be similar to the trigger's. But in stored procedures you can sometimes do some extras, like deactivating foreign keys (not sure about SQL Server though).
DELETION SCRIPT
This is the most powerful, as you can mix DDL and SQL and do all sorts of stuff. But scripts usually have to be run manually, which might not be acceptable in your case.
Ok. I've tried the trigger, but it didn't work.
I have Cascades from A to Linker and from B to Linker, Cascade from Users to A, No Action from Users to B.
My trigger is on Users and is as follows:
set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
go
ALTER TRIGGER [trig_delUser] ON [dbo].[aspnet_Users]
FOR DELETE AS
SET NOCOUNT ON;
DELETE FROM B WHERE B.UserId = Deleted.UserId
I get the exception: The DELETE statement conflicted with the REFERENCE constraint "FK_B_aspnet_Users"
I am working with a modified aspnetdb
SQL database:
[Partial DB diagram][2]
I have cascade deletion on the
B_Linker relationship and the A_Linker
relationship and there doesn't seem to
be any danger of cycles occuring.
When I delete a user, I would like all
A entries and B entries to be deleted
along with any associated linker
entries; unfortunately, SQL mgmt
studio will only let me put a cascade
delete rule on EITHER aspnet_Users_A
or aspnet_Users_B, not both.
What do I need to do?
Many Thanks.
[2]:
http://i48.tinypic.com/2nsnc3k.png
This is one of the unfortunate and frankly rather annoying limitations of SQL Server.
It's not the fact that there could be cycles that's the problem, it's simply as the error says - you have multiple cascade paths to the Linker table. The first is aspnet_Users -> A -> Linker and the second is aspnet_Users -> B -> Linker.
You only really have a couple of choices:
Choose one path to implement the CASCADE on and set the other to NO ACTION. Then write a Stored Procedure that deletes the non-cascaded child entities before deleting the parent entities in order to prevent a foreign key error. Or, don't CASCADE either and have your SP do the cascading for both.
Don't add a foreign key at all on the second relationship; instead, use a FOR DELETE trigger on the parent to delete the child entities. I very much dislike using triggers for RI, but this isn't much worse than the first option. In some ways it's better, because database clients don't have to worry about your specific implementation of the FK relationships.
Neither are ideal, but there is no perfect solution other than to change your design. If it is possible for you to change your schema such that you don't have multiple cascade paths, that would be the best thing to do - but I recognize that there are (many) real-world situations where this is not possible. Not knowing the specifics of your schema, I can't say for sure whether or not there's a more optimal design.
I would not implement this through on delete cascade. Or through a trigger. What would happen if someone needed to delete 40,0000 records all at once. You would lock up the parent and all the child tables possibly for minutes possibly hours while it runs through and does it's thing.
So really what you should do is write the deletes to the child tables first then the delete to the parent table and put them in a transaction. This will work well enough when you are delting one record at a time. Large deletes should be written separately (don't loop throuhg the existing proc) and are another subject, but at least now you can do them without killing your server.
You just have to put the ON DELETE CASCADE rules on the foreign keys.
Can anyone provide a clear explanation / example of what these functions do, and when it's appropriate to use them?
Straight from the manual...
We know that the foreign keys disallow creation of orders that do not relate to any products. But what if a product is removed after an order is created that references it? SQL allows you to handle that as well. Intuitively, we have a few options:
Disallow deleting a referenced product
Delete the orders as well
Something else?
CREATE TABLE order_items (
product_no integer REFERENCES products ON DELETE RESTRICT,
order_id integer REFERENCES orders ON DELETE CASCADE,
quantity integer,
PRIMARY KEY (product_no, order_id)
);
Restricting and cascading deletes are the two most common options. RESTRICT prevents deletion of a referenced row. NO ACTION means that if any referencing rows still exist when the constraint is checked, an error is raised; this is the default behavior if you do not specify anything. (The essential difference between these two choices is that NO ACTION allows the check to be deferred until later in the transaction, whereas RESTRICT does not.) CASCADE specifies that when a referenced row is deleted, row(s) referencing it should be automatically deleted as well. There are two other options: SET NULL and SET DEFAULT. These cause the referencing columns to be set to nulls or default values, respectively, when the referenced row is deleted. Note that these do not excuse you from observing any constraints. For example, if an action specifies SET DEFAULT but the default value would not satisfy the foreign key, the operation will fail.
Analogous to ON DELETE there is also ON UPDATE which is invoked when a referenced column is changed (updated). The possible actions are the same.
edit: You might want to take a look at this related question: When/Why to use Cascading in SQL Server?. The concepts behind the question/answers are the same.
I have a PostGreSQL database and I use On Delete when I have a user that I delete from the database and I need to delete it's information from other table. This ways I need to do only 1 delete and FK that has ON delete will delete information from other table.
You can do the same with ON Update. If you update the table and the field have a FK with On Update, if a change is made on the FK you will be noticed on the FK table.
What Daok says is true... it can be rather convenient. On the other hand, having things happen automagically in the database can be a real problem, especially when it comes to eliminating data. It's possible that in the future someone will count on the fact that FKs usually prevent deletion of parents when there are children and not realize that your use of On Delete Cascade not only doesn't prevent deletion, it makes huge amounts of data in dozens of other tables go away thanks to a waterfall of cascading deletes.
#Arthur's comment.
The more frequently "hidden" things happen in the database the less likely it becomes that anyone will ever have a good handle on what is going on. Triggers (and this is essentially a trigger) can cause my simple action of deleting a row, to have wide ranging consequences throughout my database. I issue a Delete statement and 17 tables are affected with cascades of triggers and constraints and none of this is immediately apparent to the issuer of the command. OTOH, If I place the deletion of the parent and all its children in a procedure then it is very easy and clear for anyone to see EXACTLY what is going to happen when I issue the command.
It has absolutely nothing to do with how well I design a database. It has everything to do with the operational issues introduced by triggers.
Instead of writing the method to do all the work, of the cascade delete or cascade update, you could simply write a warning message instead. A lot easier than reinventing the wheel, and it makes it clear to the client (and new developers picking up the code)