Occasionally you may develop a feature for mojoPortal where you need to access a different database than the mojoPortal database for various reasons. Of course in your data layer you may use a different connection string than the one used by mojoPortal to access your database. In some cases you may wish to still be able to use the mojoPortal Setup system to install your tables and other database object like stored procedures. As of 2010-08-29 we have implemented a simple convention based solution to make this possible. It does require the code as of 2010-08-29 or newer.

Example Scenario

We needed had a customer with a mojoPortal site that needed a feature on their site which would manipulate data from a database other than their mojoPortal website's database. We developed a simple method to make it possible to use an alternate connection string but still be able to install the custom feature with the mojoPortal setup page, allowing the tables and procedures for the custom feature to be installed in a different database.

The first piece of the puzzle is making the data layer use an alternate connection string if it is found in appSettings, or if not then just use the mojPortal connection string. Code like this can solve the problem:

using System.Configuration;

namespace ACME.CustomFeature.Data
{
    internal static class ConnectionString
    {
        /// <summary>
        /// Gets the connection string for read.
        /// </summary>
        /// <returns></returns>
        public static string GetConnectionString()
        {
            if (ConfigurationManager.AppSettings["ACME_CustomFeature_ConnectionString"] != null)
            {
                return ConfigurationManager.AppSettings["ACME_CustomFeature_ConnectionString"];
            }

            return ConfigurationManager.AppSettings["MSSQLConnectionString"];
        }
    }
}

This allows us to use get our connection string with ConnectionString.GetConnectionString() from classes within our ACME.CustomFeature.Data namespace.

Notice the convention in the alternate connection string is [ApplicationName]_ConnectionString where [ApplicationName] corresponds to the folder name under /Setup/applications/[application]. So, to use the setup page it requires that the scripts are located under /Setup/applications/ACME_CustomFeature/ and below that folder, is SchemaInstallationScripts/[dbplatform] and SchemaUpgradeScripts/[dbplatform] where [dbplatform] is mssql, mysql, pgsq, or SQLite and version specific script files go into this folder.

The alternate connection string must be specified in the user.config file before you run the setup page. So the first step should be to establish the alternate connection string before installing any files. In our example, the connection string would be: <add key="ACME_CustomFeature_ConnectionString" value="server=ServerName\SQLInstance;UID=yyyyyy;PWD=xxxxx;database=theOtherDatabase" />

The logic behind the setup page looks for the convention based connection string [ApplicationName]_ConnectionString based on the application folder name, if it finds a value it passes this in as an override connection string when running the scripts, otherwise it just uses the main connection string.

Note however, that the schema version for the feature is still going to be recorded in the main site database in the mp_SchemaVersion table, and things like module settings also will still be stored in the main database. Also keep in mind that the use of an alternate database means you can't really join to any mojoPortal tables in your custom feature. It can only be useful when the data in the alternate database is completely self contained and independent of the site data.

One final note, if your feature doesn't need to use the database portions of the setup page, you don't need to worry about the name of your feature folder. Having the alternate connection string in the user.config and then referencing it your code is enough.