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.
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.
John
Free DotNetNuke News, Tips, Strategies and more.
www.dotnetnukesites.com
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.
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.
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
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
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
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.
kevlingo
Member
40 Points
8 Posts
Firebird Provider
Aug 17, 2005 09:22 PM|LINK
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
kevlingo
Member
40 Points
8 Posts
Re: Firebird Provider
Aug 19, 2005 05:25 PM|LINK
Kevin Lingofelter
gmanupnorth
Member
405 Points
81 Posts
Re: Firebird Provider
Aug 19, 2005 06:18 PM|LINK
Hopefully someone else can shed some light on this for you.
"The Library...were we bury the lies."
phr0ze
Contributor
2120 Points
424 Posts
Re: Firebird Provider
Aug 19, 2005 07:27 PM|LINK
Free DotNetNuke News, Tips, Strategies and more.
www.dotnetnukesites.com
adefwebserve...
Contributor
5912 Points
1207 Posts
MVP
Re: Firebird Provider
Aug 19, 2005 08:26 PM|LINK
Open Light Group
LightSwitchHelpWebsite.com | ADefWebserver.com
leupold
Contributor
6015 Points
1197 Posts
Re: Firebird Provider
Aug 19, 2005 08:26 PM|LINK
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
gamma concept mbH
DeutschNetNuke = DotNetNuke in German
DNN Project UserDefinedTable
adefwebserve...
Contributor
5912 Points
1207 Posts
MVP
Re: Firebird Provider
Aug 19, 2005 08:48 PM|LINK
Open Light Group
LightSwitchHelpWebsite.com | ADefWebserver.com
smehrotra75
Participant
1360 Points
272 Posts
Re: Firebird Provider
Aug 19, 2005 09:38 PM|LINK
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.
leupold
Contributor
6015 Points
1197 Posts
Re: Firebird Provider
Aug 19, 2005 10:27 PM|LINK
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
gamma concept mbH
DeutschNetNuke = DotNetNuke in German
DNN Project UserDefinedTable
smehrotra75
Participant
1360 Points
272 Posts
Re: Firebird Provider
Aug 19, 2005 10:48 PM|LINK
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.