Blog achief

Onze weblogs / Our Weblogs


Cleaning module data after portal deletion

jan 06 2009

Yesterday I have been working to create a seperate DNN installation that consists of 4 portals from a larger DotNetNuke install. That is quite a tedious process, especially if there are a lot of portals that need to be deleted. In this case more than 30 portals needed to be deleted. DNN throws in a nice touch by timing out the application after every portal that is deleted. Setting all portals to expired and delete them all in all go doesn't work either... due to timeouts, and due to the fact that if a portal deletion fails, the whole process stops.

Another problem you will run into when deleting portals is that some modules are poorly designed. For instance, tables might have a foreign key defined to the DNN Portals table, but if cascade delete is not enabled, deletion of the portal will fail if the module table contains data for that portal.

Another issue is when modules store data without foreign keys to either the Modules table or the Portals table. In this case, orphaned module data will stay behind after the portal is deleted. This happened with (at least) 2 modules that were running on the install: Form Master and an old version of Compete Form Designer.

 This was the SQL I executed to clean out data for those to modules:

      WHERE portalid not in (select portalid from portals)
      WHERE portalid not in (select portalid from portals)

Delete from cfd_ctrls where moduleid not in (select moduleid from modules)
Delete from CFD_Ctrl_Detail where cId not in (select id from cfd_ctrls)

Note to self: I really need to look into multip portal deletion. This just takes way too much time!

Inloggen      Copyright 2009 interApps - websites & internet oplossingen   
donderdag 4 juni 2020