Most developers will create a foreign key constraint between the ModuleID column of their custom table(s) and the ModuleID column of the DNN Modules table with Cascade Deletes turned on.  When the module instance is deleted from the DNN Modules table (when finally deleted from the Recycle bin), all related table records for this ModuleID should also be deleted. I've generally followed this pattern but don't feel entirely comfortable with it - when I think of the potentially hundreds of module definitions creating foreign key constraints on the DNN Modules table. I keep meaning to look into doing this with a sql trigger rather than foreign key constraint but can't seem to get around to it.  Any one tried this? Pros . . . cons?

Other developers prefer to leave orphaned data in their custom tables when a module instance is deleted figuring that all of their custom tables will be deleted anyway when the module definition itself is deleted - thanks to the UnInstall.SqlDataProvider script that should be included in each module package.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner

Hello!

William, your explanation is very clear, thank you very much!

Sebastian, thank you for your response, could you please give me an example on how to use a trigger? Or could you suggest me a module that use this method? What do you mean with "deletion would be handled by business logic"?