Hello,

I am a new DNN user. From what I've seen, this is a great framework to work with! I am really excited to develop modules specific to the industry I market to. I wish I would have found this a year ago!

One thing I am curious about: I've seen some posts about porting the data provider to other RDBMS. I've seen the Oracle provider and have seen talk about a Firebird one. Has anyone put any work into this?

I am an avid Firebird user as it gives me the ability to provide enterprise level functionality without all those zero's in the price tag...=) (it is, in fact an open source project with a very liberal license, not unlike DNN).

I'm just digging in to the DNN book (from the core team) now, so I have a lot to learn. I look forward to gleaning the resources this community has to offer and hope to contribute whatever I can.

Kevin Lingofelter

Just a little bump...anyone?

Kevin Lingofelter

There is currently no provider listed on Snowcovered (http://www.snowcovered.com/snowcovered2/Default.aspx?tabid=139&mastercategoryid=16&subcategoryid=67) for Firebird.........but this does not mean that one is not in development.


Hopefully someone else can shed some light on this for you.

Using something other than SQL Server really becomes risky unless you get the source to the provider and never plan on using 3rd party modules. Still it becomes another peice to maintain.  The pricing on SQL Server is not that bad either. Free with limited users or as low as $500 for unlimited users.

It is very possible to make a FireBird provider for DotNetNuke. An Oracle provider has been made so yes it is possible. Once this provider is made it can then be sold or made avaliable free to the community.

If someone seriously wanted to pursue this I and others are willing to answer questions and show you how to do it.

As a side note, most work on this Firbird provider would NOT be wasted if the Core decides to go with the DAL II proposal. The stored procedures that need to be created would be used if the Core decides to use the the DAL II design. The difference between the current DAL design and the DAL II design is that the DAL II design does not need the "data provider" assembly.

Kevin,
please realize, that having a database provider for another Database then MS SQL-Server coveres only the DNN Core framework and core modules - it limitates your possibilities of using other modules and providers, as you woould need additional database providers for the additional components as well. Although this is possible, the effort can easily grow enormous, therefore most of the installations stick to the default provider. Tanikg in account, that SQLServer MSDE is available for free and sufficient for smaller web sites, Web Hosting with SQL-Server became cheaper and cheaper during the last month and SQLServer 2005 Express will be for free as well and suitable for small and medium sized web sites I do think, that this will not change much in the future - even when a new data provider concept reduces the efforts for programming additional data providers.
Sebastian

Also if a person ran DotNetNuke using the FireBird provider they could still buy modules and easily convert them to run on firebird. yes they would have to create a "data provder" assembly, but this is something that is very straight forward. You simply create a Firebird stored procedure for each SQL stored procedxure (in most modules youare talking about 5-10 very simple CRUD stored procedures), then code methods to call the stored procedure.

Since your DotNetNuke instal has been configured to run with FireBird it will automatically load this assembly (because it has been properly named).

You will not have to change the code of the module or re-compile it.

leupold wrote:

Kevin, please realize, that having a database provider for another Database then MS SQL-Server coveres only the DNN Core framework and core modules - it limitates your possibilities of using other modules and providers, as you woould need additional database providers for the additional components as well. Although this is possible, the effort can easily grow enormous, therefore most of the installations stick to the default provider. Tanikg in account, that SQLServer MSDE is available for free and sufficient for smaller web sites, Web Hosting with SQL-Server became cheaper and cheaper during the last month and SQLServer 2005 Express will be for free as well and suitable for small and medium sized web sites I do think, that this will not change much in the future - even when a new data provider concept reduces the efforts for programming additional data providers. Sebastian

I beg to differ. The possibilities of using other modules with different providers is only limited by the capability of the person who is attempting to develop them. If someone has created a module using the standard set forth by the core, it is quite easy to create different data providers for the module. As Kevin has correctly pointed out, if someone purchases a MS SQL version of any module and can write SQL for firebird, it is very easy to create a firebird version of the module. The biggest pain is felt when creating the core scripts for a different database. I have started down this path for firebird but have not been able to complete it for various scheduling reasons.

smehrotra75 wrote:

The possibilities of using other modules with different providers is only limited by the capability of the person who is attempting to develop them.

I did not mean, that it is not possible to write data provider. 

smehrotra75 wrote:

If someone has created a module using the standard set forth by the core, it is quite easy to create different data providers for the module.

I disagree (even with michael), that the effort is very small. This might be correct for small ones as most of the old core modules, but if it comes to modules with larger functionality, SQL scripts and providers become larger (the biggest Script I just found is for nSurvey and has 485 kB or 15437 lines) and need some attention - even the core provider for 3.1  has problems with OQ and DBO. So there is additional effort, and it is always a decision, if it is worth it. I pointed out, that I do not expect many DNN users with other databases in the future - so the market will remain small. If you have customers willing to pay your effort (or you don't need to work for money and sit in front of your PC because you don't know anything better to do) than it will be fine for you to conquer the rubicon.
Good luck!
Sebastian

leupold wrote:

smehrotra75 wrote: The possibilities of using other modules with different providers is only limited by the capability of the person who is attempting to develop them. I did not mean, that it is not possible to write data provider.   smehrotra75 wrote: If someone has created a module using the standard set forth by the core, it is quite easy to create different data providers for the module. I disagree (even with michael), that the effort is very small. This might be correct for small ones as most of the old core modules, but if it comes to modules with larger functionality, SQL scripts and providers become larger (the biggest Script I just found is for nSurvey and has 485 kB or 15437 lines) and need some attention - even the core provider for 3.1  has problems with OQ and DBO. So there is additional effort, and it is always a decision, if it is worth it. I pointed out, that I do not expect many DNN users with other databases in the future - so the market will remain small. If you have customers willing to pay your effort (or you don't need to work for money and sit in front of your PC because you don't know anything better to do) than it will be fine for you to conquer the rubicon. Good luck! Sebastian

Sebastian - have you tried to create a module for another data provider? A lot of times I've seen posts like this from people who are very quick to point out that something is not possible or very hard to do when in reality, they've not even tried it.
With regards OQ and dbo - this is a mute point with Oracle. Oracle has a much more elegant way of handling the qualifiers and this has been utilized to avoid some of the headaches found on the SQL Server side.
We are just about wrapping up an ecommerce site for a company that runs on the Oracle dp and has about 30 different modules that do various things from shopping carts, credit card authorization to very complex product catalog grids. In each and every case the SQL version of the module can be created in less than a day and without requiring the recompile of the Module or DNN. Like I mentioned before, the ability to create a module is dependant on the skills of the person doing it. If you are well versed in the SQL language of the particular database, it is very easy to create the data provider for any module.
I don't think the market for other db's running DNN will remain small or non-existent. There is effort under way with the new DAL by Michael plus the Oracle dp has been out for over a year now. I believe there is also a provider for Sybase (or it's offshoot) that someone else has also written for DNN. There are different db platforms besides MS SQL Server and there are enough companies out there that don't use MS SQL - why shouldn't we offer the benefits of DNN to those users too....
I will refrain from addressing your portion of the comment about sitting infront of a pc because I don't know anything better to do because it's doesn't justify a response.

Here's an alternative: in theory, it should be pretty easy to use a combination of two separate database engines for the same site.  I am contemplating this for an ASP.NET web application that I wrote against Firebird database.  I plan to enable DNN sites on this same server via MS SQL Server, and then "wrap" much of this web application into DNN modules, and voila, I've made this web application a dnn site, ready for announcements, forums, etc..  This would allow me to migrate the entire app to SQL Server (or not) at my liesure, especially when using the dataprovider pattern.

While it is possible to simply create a module that talks to your FireBird server, I jumped in on this thread because I wanted to encourage someone to make a FireBird provider for the DotNetNuke core code and share it with the community.

Shaun Walker created a Data Access Layer that allows virtually any datasource to be used with DotNetNuke. This allows DotnetNuke to grow. The problem is we need people to step forward to actually create the additional providers. I am willing to help.

Michael - the plan was to write the firebird provider and release it to the community. But as you're probably aware - the "paying/paid" projects take precedence over the freebies. I am hoping that within the next couple of weeks (when things slow down a little bit), I'll get a chance to go back and finish the scripts. You've already seen the provider itself. It's ready except for the stored procs which takes the longest time to do....

What's the benefit of using firebird over msde?

Is there really a compelling reason to want to take on this maintenance workload?

MSDE does have limitations:

• Does not scale to large web sites due to connection governor
• Runs on only up to two processors.  (I'm not sure if this is a licensing issue or if there is a governor for this as well).  Firebird itself can use only one processor, but you can run it on a multi-CPU machine.  This could be considered an advantage because the Firebird engine will never use more than 25% of the CPU power on a 4-CPU box, leaving the rest of the CPU for other tasks.

More importantly, for the same reasons that it makes sense to develop and maintain an Oracle provider, there are compelling reasons to impmlement a Firebird dataprovider:

• There are existing applications written against Firebird. 
• People who are already a Firebird "house" would have a much easier decision about taking advantage of DNN, and the DNN community would grow even more.