views:

618

answers:

4

I have a few tables where Foreign Key constraints are added. These are used with code generation to set up specific joins in generated stored procedures.

Is it possible to override these constraints by calling multiple deletes within a transaction, specifically "TransactionScope" in C# or is cascaded deleting absolutely required?

+1  A: 

You can't override FK constrains, if you could what would be the point of creating them in the first place?

Otávio Décio
true, what I mean is, I guess: is that the foreign key constraint/references wouldnt be validated/checked on the rows until the end of the transaction so cascading deletes would'nt need done.
Mark Redman
I don't believe so; even inside a transaction the relational integrity is enforced. You can disable the FK's as OMG points out.
Otávio Décio
@Otávio Décio: Thats a pity the integrity isnt check at the end of a transaction (or enabled/configured to do so), it would help.
Mark Redman
+1  A: 

The only way to "override" a foreign key constraint is to disable it:

Disabling a FOREIGN KEY constraint enables data in the table to be modified without being validated by the constraints. Disable a FOREIGN KEY constraint during INSERT and UPDATE statements if new data will violate the constraint or if the constraint should apply only to the data already in the database.

You need to use the ALTER TABLE command to disable a constraint, using the NOCHECK keyword. IE:

ALTER TABLE dbo.cnst_example NOCHECK CONSTRAINT salary_cap;

The only other alternative is to drop the constraint, and re-add when necessary.

The necessity of doing this should lead to discussions about how to model the tables so this is not necessary.

OMG Ponies
+1, exactly what I was thinking, if the FK exist only for a code gen utility to make some stored procedures, then dropping them wouldn't really be a problem then.
KM
KM: We do code gen a lot, usually delete the constraints for production databases and also rarely delete any records. So the constraints are usually not an issue. In out new Multi-Tenancy model we were thinking of keeping them in, but deleting a whole Tenant, which is required, gives us this Foreign Key issue. I would rather not disable/enable or drop/create the constraints. I guess we could carfeull consutruct the order of deletions (which seem like an obvious choice, or we can just not use the constraints as you mention.
Mark Redman
@Mark Redman: Data integrity is highly questionable if there are no constraints in place.
OMG Ponies
@OMG Ponies: It depends what else is looking after the integrity, but generally yes, I agree.
Mark Redman
+2  A: 

Do not use cascade delete, you can cause serious performance issues that way. The best procedure is to do the deletes in order from the lowest child table up to the parent table.

Disabling the foreign keys is a prescription for having data integrity problems. The only time something like that should be done is by a DBA who is extremely experienced and well aware of the issues that could cause. If you are asking this question, you are not yet experienced enough to use that technique. Remember when you disable the FK, you disable it for everyone not just your process.

HLGEM
OP says: `...Foreign Key constraints are added. These are used with code generation to set up specific joins in generated stored procedures.`
KM
@HLGEM: I agree that in this situation (described in one of my comments on another answer) carfully deleting in the order of the lowest child is probably the best option.
Mark Redman
+1  A: 

If your FK constraints are specifically set for specific use in stored procedures, these are not really FK's, aren't they? a nice solution would be to update the corresponding code by creating the constraints at the beginning of the proc, and clearing them when your code is done. Do not forget then to deal with the case where your temporary constraint cannot be checked against the data.

Philippe Grondier
They are used to setup some joins in the code generation (selects etc), but do work as designed if FKs are left in.
Mark Redman