Mitch,

I do not have the least bit of interest in "falling inline with the hype of new features" and it is wrong for you to make that assumption about me. So instead of making assumptions about me, let's discuss the substantive benefits. I do not have the time to implement something for the sake of hype. I will not implement something unless it has genuine functional utility for me. 

In a previous post, I provided a link to the MSDN article that lists the benefits of the new separation of schemas from owners (ie, security principals). There are important consequences for applications where security is more important than used by the typical DotNetNuke web site to date. So if you have any interest in promoting DotNetNuke for use in new and different industry sectors where security may be a more critical concern, then it would be more constructive to be more open-minded about these matters.

Also, I have never made any statement about stopping support for Microsoft SQL Server 2000, or for Oracle, or whatever. I have repeatedly described my interest in a new mechanism implemented with a switch, appropriate diagnostics and failsafes, overall allowing for the optional use of the new mechanism I plan to implement for my own purposes and my own modules.

I began this thread with a simple inquiry regarding what the Core Team may or may not be doing and/or planning. Based on the feedback in this thread, it is quite clear that not only is nothing being done, but there appears to be quite a bit of ... shall I say... reluctance to encourage innovative development of experimental approaches for alternative mechanisms of whatever kind involving the database provider. I hope that attitude changes to a different more positive and optimistic one that encourages all DotNetNuke community members to be active and innovative regardless of whether they are members of the Core Team and regardless of whatever core service, function, feature, module that person may be interested in. Frankly, I thought that is what open source is all about.... or maybe I'm just a newcomer to the open source world, and as an old-timer from the closed-source world, maybe I just don't get it yet... so what am I missing? 

CT

I second Mitch's comments about apologizing if post came across as angry or offensive. You have to also understand that we (people on the forums) see on a regular basis people who do come and just make statements about this or that - but when push comes to shove, there's nothing to show from these same people.... 

My comments also weren't specifically around being ANSI compliant or not (In the case of Oracle and SQL Server, both now are ANSI compliant so I'm a happy camper)... My comments are instead more around making sure that there isn't functionality that is included inadvertently in the core which causes it to not work with any other database platform. A good example is GUID's... In SQL Server, this is a valid datatype, whereas it isn't in Oracle. If you create core functionality that builds on this, inadvertently you'll be creating problems for other dataproviders. Another good example is the use of NULL verses empty strings. Both are handled differently from platform to platform (and sometimes even from version to version of the same database platform)... 
No one is doubting your area of expertise, however please do understand that some of us making comments on this thread too have been working in the "real world" for many years now (especially with DNN) and are making such comments based on our knowledge or expertise with working with diversely different environments...

Sanjay

Sanjay,

AFAIK it just works this way round, if you created a user, assigned a schema this will be used automatically for created objects by this user. DotNetNuke also use for security reasons to provide a second connection string for DDL tasks, please refer to the "Hardening Security" documentation, available from Resources > Documentation > Downloads item in Menu above.

When I stated, that there are no current plans for breaking changes, the core team is well aware of development in all areas and evaluates options for improvement, e.g. Linq to Entities in ASP.Net 4 or Entity Frameworks, but those changes will need to be considered well and might take effect in DNN 6, 7, 8 or 74.