Scott,

the Core Team is trying its best to improve the product without breaking changes and there are NONE planned in the public interfaces for DNN 5. We still continue to support SQL 2000, ASP.Net 2.0 (i.e. 3.0 and 3.5 are not required).

---

Cheers from Germany,
Sebastian Leupold

   

Speed up your DNN Websites with TurboDNN

CT,

From a technical perspective the way that each module developer writes their SQL scripts etc, if you put something in place that modifies those queries you are opening up a huge point of failure to your DNN installation, and also pull yourself outside of ANY potential for support from the module developer, at least in most cases.

I don't see the major need for this change....everything works perfectly fine as it is, and there are no performance implications of making the change.  It appears to be more of a desire to fall inline with the hype of new features for the sake of saying that you can implement it.

I am all for change, however, as the above people have pointed out DNN must cater to the large community, and at this point dropping support for SQL Server 2000 would not be a good thing....as many people are still running on it...

---

-Mitchel Sellers
Microsoft MVP, ASPInsider, DNN MVP
CEO/Director of Development - IowaComputerGurus Inc.


Visit mitchelsellers.com for my mostly DNN Blog and support forum.

Visit IowaComputerGurus.com for free DNN Modules, DNN Performance Tips, DNN Consulting Quotes, and DNN Technical Support Services

Sanjay,

I appreciate your concerns.

Standards can be both good and bad. They are good when they promote interoperability between diverse platforms, systems, environments. They are bad when they discourage and/or prevent innovation, progress, and exploiting the benefits and advantages of a particular system.

Presumably, it is possible to have the best of both worlds, ie, interoperability between systems while simultaneously allowing for full exploitation of unique systems. A properly designed framework should allow for this possibility by clarifying what is required for the abstract data provider (supporting DotNetNuke) and what is permitted for the concrete data providers for each of the unique backend data stores (supporting Oracle versus Microsoft versus whatever).

So really your concerns address the underlying debate about whether to adhere to the ANSI SQL standard or not when it comes to supporting all backend data stores. Well I guess that boils down to whether or not there's a desire to ignore or to exploit those Microsoft SQL Server features that offer benefits but fail to comply with ANSI SQL Standards!!!

Also, since I have been getting quite a number of remarks that seem to assume this or that about me, perhaps I really should say a word about myself as welll as about some assumptions in general. Just because a programmer is a newcomer to DotNetNuke and may wish to ask questions and discuss topics in this forum, that does not necessarily mean that that programmer is a newcomer to Microsoft technologies or to programming and development in general.

So just to set the record straight, I have been working with computer hardware and software since the 1970's, I have programmed in everything from assembly to many of the higher level languages that have been popular since that era. So you folks out there need not worry about whether I am "naive" about either programming or development practices or the amount of effort and time to accomplish whatever.

CT

---

CT