Can you run DotNetNuke on Oracle?

A few days ago I was surfing through the forums on and came across a post asking if you could run DotNetNuke on an Oracle database.

In short, yes you can. But why would you? This blog post will talk about that, and some of the reasons why I would never recommend that you use DotNetNuke on Oracle. (No offense intended to anyone who provides Oracle support for DNN, this is simply my personal opinion)

DotNetNuke is built with a provider model, what does that mean? It basically means that you can swap out functionality fairly easily. One of those providers is the database layer of the platform. DotNetNuke is built to run out of the box on Microsoft’s SQL Server, but there are other providers out there such as one for Oracle databases from a company called Acuiti Solutions.

Plugging in a data provider for Oracle will basically allow you to configure DotNetNuke to run on Oracle, bypassing the requirement for Microsoft’s SQL Server. Sometimes this is a business requirement, based on licensing concerns within an organization, sometimes it’s just a preference for people to stick with a database that they already know and love.

While I haven’t setup DNN to run on Oracle, it should be a fairly straightforward process, setup the database, setup the connection information, change the provider settings in the web.config, boom you’re done (maybe, like I said, I’ve never done it).

What now? Well, I imagine you go about installing DNN as you normally would, the difference being that it’s all setup on Oracle, instead of SQL Server. So you install, login, and start creating some pages. But you realize you need some custom functionality, so you look for a DotNetNuke Module to provide that functionality, perhaps it is one of the Core modules from the DNN project, then you are likely in luck as it looks like Acuiti provides you the required dataproviders for a lot of the core modules to interact with Oracle.

But what if you want to use a module from another vendor? Chances are that every one module out there written for DNN will NOT work with Oracle out of the box, not at least until you get an Oracle dataprovider for that module, and there in lies the catch to this whole idea. For each new module you want to use on your DotNetNuke install you will need to get an Oracle data provider, you are not likely to find that existing already so you will have to develop it yourself, or pay someone else to develop it. That will potentially increase your costs dramatically!

So, in short, you can use DotNetNuke on an Oracle database, but i wouldn’t encourage any of my customers to go down that route.

On a somewhat related note, just because you install DNN on a Microsoft SQL Server database doesn’t mean that all your modules must interact with MS SQL, you could easily write your own module that uses it’s own connection string and connects to an existing Oracle database somewhere to provide content and functionality from other business solutions. The provider model for DNN can be used to do this, or you could bypass the provider model and simply develop your custom module to talk to Oracle without the use of a provider.


  • so taking in consideration my previous comment, taking it to oracle or DB2 or whatever , is realy quick and easy. (if the 3e module vendors also use this system of course).
    I know my little comment wont change the ways as is, but i like to know why i'm the only one doing this?

  • Developers aren't writing for oracle because there isn't enough of a market to make it worth the effort, IMHO

  • Hi Chris,
    this comment of mne is not saying anything without the first one i submitted. did you not receive this?
    Best regards

  • Olivier, I never received another comment from you on this topic, only the one displayed.

  • what i ment is: dnn (and microsoft) are making life complex by creating a DAL layer for every select/update statement. I use an implementation for all possible sqlhelper access methods (idatareader, dataset, scalar, ...) (like for example: public function select_sql(mysql as string) as idatareader)
    So every time i need to access sql in a new way, i dont need to write the 3 parts of the datalayer. (abstraction; implementation, bussiness layer)
    If everyone uses this way, going to oracle would be no pain at all, because you have NO functions to rewrite with a new oracle-implementation.

    if you need more info on this, dont hesitate to write me:

  • Chris - saw this post today and although this is an old blog wanted to make sure I point out some "problems" with your statements above.
    Just because you happen to use SQL Server and DNN was originally built on SQL Server does not mean that this is enough reason not to use DNN on any other platform. DNN has been running on Oracle since version 2x and I'm pretty sure that the companies using DNN and Oracle saw the potential value of using a good Open-source .NET framework (DNN) on their existing database platform (ie Oracle). There are a lot of big shops out there who WILL NOT bring in SQL Server into their organization and by limiting the choices to the users is simply a bad business model in my mind.
    Part of the problem with the core team has been a lack of understanding of anything BUT SQL Server and this is reflected in the constant limited scope mentality often displayed in the core (for example cutting out the provider piece, etc).
    You mentioned that the costs are raised dramatically and I would challenge you to provide examples? In more than 100+ cases where I've converted over existing 3rd party modules to Oracle, it's been simply creating the scripts to handle the db stuff and then creating the oracle dataprovider dll - all stuff which you'd do in any case when you create a module. And at no time has this been something which raised the costs dramatically. In fact there are clients who often do this themselves since they are already familiar with Oracle.
    At the end of the day, this might sound like a rant but remember that there are more db platforms out there than just SQL Server and the fact that DNN is supported on Oracle for 5+ years (without any support from the core team) should be a plus for DNN and not viewed as a negative thing.

  • Sanjay, thanks for the comments. As stated, the post was just my opinion, not trying to knock on anyone making oracle and DNN work. I think Oracle is definitely an option for those people who absolutely cannot use SQL.

  • It is a real pity that DNN does not natively support Oracle and other databases. Based on my experience, I see this as a huge mistake. As a consultant I have had to walk away from several big clients who are married to Oracle and would never take on the cost of managing another database.

Comments have been disabled for this content.