Ahmed,

Let me commend you on your bravery. You're ready to go right to the series of tables in the DNN database to debug at the database level why a module was not inserted.

I'd have to trace out in the current database where this all happens to what tables and what all dependencies are involved.

I had to work that all out once to get data from sites running on 3.x to sites running on 4.x. DNN has long since prior come out with an update procedure to do this. Fortunately, you won't need to go to the database level to resolve your issue.

If your module isn't showing up in the drop down list, there are a number of simple reasons why.

Go to the Extensions page, where the list of all modules exists. Does the module show up there? it should and if so, click on the pencil icon to edit it. Scroll to the bottom of the page -- are there view, settings and edit controls set up? Next, is the folder where the module lives in Desktop Modules existing? Browse to the Website \ Desktop Modules\ directory and find the folder in this directory. It should be there. There is a "Folder" text box on the module edit screen -- is there a typo for the folder name?

In visual studio (or visual web developer), open up the module folder and find all .ascx (control) pages. Are all of these listed at the bottom of the module edit screen?

On the module edit screen make sure all controls are present and they have proper keys, the folder name is spelled correctly, that there is a friendly name (this is what shows up in the drop down list, I think)

If I'm interpreting your post correctly, there is some simple basic missing right on this page. Finding it in the database (or not) will prove there is an install issue but you should not have to go that far -- the error will show up right on this page.

Ahmed,

To answer the question straight up, yes I do.  Just go into SSMS (SQL Server Management Studio) and right click on the table.  Select "show dependencies" and you'll see how this is done.  You'll find what stored procedures do the insert.

The way DNN is set up, there will be a stored procedure call from somewhere in the VB code after a module is created -- that is once the extension process completes.  Just look for the stored procedure name.  It will be in some sort of SQL Provider Project method.  If you're using 6.x or later the code will be in C# or at least C# is a choice.

If you have the full source code, you can find it. Exactly where does it live?  I'm not sure.  But how to find it, the above is what I'd do to find it.

This being said -- DNN is solid.  It won't leave out things like the name of a module in the drop down list.

What module is this that isn't loading?  Look in its manifest file and I'll bet a C Note against a termite-ridden fence post the entry for the drop down list is missing from the manifest.

This sort of thing missing is a BASIC. 

I'd get with the provider of the module.  Something isn't right when the manifest is parsed and the module is loaded.

Is the problem you're trying to solve is that you can't find the module in the drop down list once you've processed it through the Extensions wizard?