This is the first in a series of blog posts filed under the "Trimming the DNN Fat" category. I hope to add as many of these "tips and tricks" as I discover them.

In this edition we'll take a look at how the Module's Settings are being stored, used, and how they end up orphaned and therefore unnecessarily cluttering your database and as a result, you application footprint (Because DNN caches this data).

A lot of modules in the  DotNetNuke eco-system, commercial and non-commercial alike, provide configuration capabilities that allow its users to configure them and customize their functions to fit their particular business needs. DotNetNuke enables developers to store these settings through its existing APIs and data store. Developers no longer have to develop custom settings storage, data access, and business logic code in order to do provide this kind of flexibility. DotNetNuke stores this information in a SQL database table called ModuleSettings. The configuration options stored here, are in a Name-Value pair format. Depending on the size of your DotNetNuke portal and number of installed modules, this table can become quite large.

There a number of ways that data in the ModuleSettings table can be orphaned and although I do not intend on covering all the edge conditions, the most common reason is when one uninstalls a module from the Module Definitions page while the module is still configured on the some pages.

I created 2 scripts and provided them below. Use the first one to locate any orphaned module settings:

Select ModuleId From ModuleSettings 
Where ModuleId Not In(Select ModuleId from TabModules)

This second script can be used (at your own risk!) to clean the orphaned data up:

Delete From ModuleSettings 
Where ModuleId Not In(Select ModuleId From TabModules)

IMPORTANT: Please note that running the second "Delete" script will alter your data, and although I have personally performed this several times, and on several sites without ill-effects, it is always a good practice to back your data. Needless to say, I take not responsibility for any data-loss you will incur from running these scripts.