script to delete related rows without cascade
-
Hi, I'm looking for a way to delete a row and it's related rows in other tables(aka linked by foreign keys), but without using cascade. I want to prohibit the user from doing a cascade delete, but want to support it so the admin can remove things that don't belong there such as test data etc. I was looking for something in the direction of a script that searches the system databases for foreign keys so I can find out what is related, as I got too many tables to do it manually. Anyone who can send me in the right direction towards such a script? Using MS SQL Server 2012. Many thanks in advance.
-
Hi, I'm looking for a way to delete a row and it's related rows in other tables(aka linked by foreign keys), but without using cascade. I want to prohibit the user from doing a cascade delete, but want to support it so the admin can remove things that don't belong there such as test data etc. I was looking for something in the direction of a script that searches the system databases for foreign keys so I can find out what is related, as I got too many tables to do it manually. Anyone who can send me in the right direction towards such a script? Using MS SQL Server 2012. Many thanks in advance.
Is there any reason why you can't allow the admins cascade delete (never used it myself). I almost always find there are unrelated tables and orphaned data towards the end of a development especially if foreign keys are not implemented, I often leave this till the end of the development. I find the diagram extremely useful in the clean up phase before UAT. I think there are a number of dependency discovery tools out there including Red-Gate.
Never underestimate the power of human stupidity RAH
-
Is there any reason why you can't allow the admins cascade delete (never used it myself). I almost always find there are unrelated tables and orphaned data towards the end of a development especially if foreign keys are not implemented, I often leave this till the end of the development. I find the diagram extremely useful in the clean up phase before UAT. I think there are a number of dependency discovery tools out there including Red-Gate.
Never underestimate the power of human stupidity RAH
Never heard of foreign keys that were dependent on user role. Afaik, foreign keys are independent of user roles. I always implement foreign keys when I create the database structure.
-
Never heard of foreign keys that were dependent on user role. Afaik, foreign keys are independent of user roles. I always implement foreign keys when I create the database structure.
Nico Haegens wrote:
Never heard of foreign keys that were dependent on user role
Wat - where did you get that from? I assume cascade delete is application initiated so controlling who can use it is trivial.
Nico Haegens wrote:
I always implement foreign keys when I create the database structure
I wish - I usually have to start the development before the specs are even half done, the data structure ALWAYS changes as the users find out what they want and what they can have so FKs tend to be done when they have stopped running with the goal posts, this usually happens 2 weeks AFTER the app goes to UAT.
Never underestimate the power of human stupidity RAH
-
Nico Haegens wrote:
Never heard of foreign keys that were dependent on user role
Wat - where did you get that from? I assume cascade delete is application initiated so controlling who can use it is trivial.
Nico Haegens wrote:
I always implement foreign keys when I create the database structure
I wish - I usually have to start the development before the specs are even half done, the data structure ALWAYS changes as the users find out what they want and what they can have so FKs tend to be done when they have stopped running with the goal posts, this usually happens 2 weeks AFTER the app goes to UAT.
Never underestimate the power of human stupidity RAH
I thought delete cascade was only possible at foreign key constraint level. Afaik, Foreign key constraints don't care who is using it, be it a sql admin or an application. Could you explain a bit more, what you mean by saying cascade delete is application initiated? We might be talking about 2 different things.
-
I thought delete cascade was only possible at foreign key constraint level. Afaik, Foreign key constraints don't care who is using it, be it a sql admin or an application. Could you explain a bit more, what you mean by saying cascade delete is application initiated? We might be talking about 2 different things.
A couple of points - I stated I never use cascade delete. Yes I know that FKs are required for it to be implemented. You said you wanted to allow admin to use it but prevent users from doing so (or find an alternative). I assume when you say users they are accessing the DB via an application with no direct access to the database(note ASS U ME) which would make it a simple design issue to manage the delete functions within the app. If your users have direct access to the database then you may be able to manage it via permissions.
Never underestimate the power of human stupidity RAH
-
A couple of points - I stated I never use cascade delete. Yes I know that FKs are required for it to be implemented. You said you wanted to allow admin to use it but prevent users from doing so (or find an alternative). I assume when you say users they are accessing the DB via an application with no direct access to the database(note ASS U ME) which would make it a simple design issue to manage the delete functions within the app. If your users have direct access to the database then you may be able to manage it via permissions.
Never underestimate the power of human stupidity RAH
I have set my foreign key constraints to disallow cascade effects so there are no accidents in what gets deleted. Here is how my application works: - users can't delete, they can only archive, meaning I set a boolean field to true and the item in the database won't appear in anything in the application to the normal user. - admins can delete, but the problem is that my client doesn't have any IT minded people, so I want to prevent them to accidentily delete a whole bunch of data. Your signature suggests to me, that you are familiar with people who aren't IT minded. So what I basically want to do is: - show the admin user what the object is connected to(the list of data connected to the object) so the admin knows exactly what he is deleting - then let the admin delete the data if he is sure the data can be deleted from the database. Do you know a good solution for my problem?
-
I have set my foreign key constraints to disallow cascade effects so there are no accidents in what gets deleted. Here is how my application works: - users can't delete, they can only archive, meaning I set a boolean field to true and the item in the database won't appear in anything in the application to the normal user. - admins can delete, but the problem is that my client doesn't have any IT minded people, so I want to prevent them to accidentily delete a whole bunch of data. Your signature suggests to me, that you are familiar with people who aren't IT minded. So what I basically want to do is: - show the admin user what the object is connected to(the list of data connected to the object) so the admin knows exactly what he is deleting - then let the admin delete the data if he is sure the data can be deleted from the database. Do you know a good solution for my problem?
I would build a dedicated admin delete view where the admin can see a list of items flagged for delete, possibly a treeview if they are deep enough and allow the admin to confirm delete. Chasing down the dependency tree will be a PITA unless you know the structure intimately, the diagram should help. It does seem a lot of work to get rid of junk when you already filter it out with a flag, I presume your flag already does the cascade thing (unless you cheated and only did the top levels). Why not change the flag to a datetime and delete anything flagged older than n months/years in a purge function.
Never underestimate the power of human stupidity RAH