What we usually do for complex module systems that need to be able to redirect to each other - is set up some global portal settings.

Create a settings.ascx based on ModuleSettingsBase for one of your modules - and wire it up as the settings view for that module.

Add dropdown or just a text field to the settings page - so that you can either just enter a tabid or select from a list of available pages - the page you want to be able to redirect to.

In the UPDATESETTINGS event for ModuleSettingsBase pages all you then need to do to store a setting that can be accessed system wide is something like :

PortalController.UpdatePortalSetting(PortalId, "MyModule_SalesTabid", txtSalesTabid.Text);

From in each of your modules you can then access this setting whenever you need it

String salesTabId = PortalController.GetPortalSetting("MyModule_SalesTabid", PortalId, "-1");
Int32 intSalesTabId = Int32.Parse( salesTabId);
Response.Redirect(Globals.NavigateURL(intSalesTabId), true) 

Westa

Ok - yes while it is possible to access information about a  dnn portal directly via SQL - it is something that should be steered clear of where possible.

Instead you would be better off taking advantage of the DNN API for doing this sort of access - one of the things about DNN is that the core sql structure can and does evolve over time - whole tables have been updated / replaced in the past leaving sites that use direct sql coding totally non-functioning.

Have a look at the DotNetNuke.Entities.Modules.ModuleController api for this sort of thing

GetModuleByDefinition( )  returns a moduleinfo record for the first Module found in the site by friendly name - on the assumption that you KNOW there is only ONE instance of the module on the site.

GetModulesByDefinition() to retrieve an arraylist of moduleInfo records - for when there are possibly more than one instance of a module.

One of the things to also understand about the api is that in MANY cases the api is actually not even hitting the database - much of the core of a dnn site is managed internally by a cache controller - which holds lots of key system elements.

Westa