Since I am the original poster of this thread regarding SQL database schemas versus owners, I will try to summarize things here for everybody's benefit.

Sebastian has informed us in the most recent reply that SQL Server 2000 will continue to be supported and that there are no changes planned in the public interface for DNN 5.

Scott has asked "Why, How, and What is going to break". Let me answer as follows:

Why:

Please see significant benefits of owner-schema separation as explained by Microsoft at

http://msdn.microsoft.com/en-us/library/ms190387.aspx

which is the SQL Server 2005 Books Online article entitled "User-Schema Separation". The benefits of namespace schemas as containers with the convention of the dot character "." marking the container boundaries has proven itself over and over again. And Microsoft in the article clearly explains the distinction between the namespace schema container and the security principals who may own the containers.

How:

I will personally implement a customized data provider for SQL Server 2005 and higher which will provide the necessary switch enabling optional use of this facility for those who desire. Rhys, you are welcome to continue to criticize the implementation and judge for yourself whether it represents true functionality or what you wish to call "prettiness".  I know that it will offer me true functionality otherwise I would not bother to implement it.

What will it break:

Nothing. If I succeed in implementing it correctly with the proper diagnostics, failsafes, and switches for selection of options by the administrator, then both the current existing DNN mechanisms should operate or the new mechanism should operate as determined by the administrator's choice for use on any new customized modules. Obviously I cannot make the new mechanism operational on the Core, but I can make it applicable to any new modules separate from the core including my own new modules.

When:

I will wait until there's a public release of DNN 5 beta before beginning work on this customized data provider, and wait until there's a stable release of DNN 5 before releasing my customized data provider. Anybody interested in working on this with me - whether to discuss requirements or to help with coding - is welcome to contact me. 

CT wrote Since I am the original poster of this thread regarding SQL database schemas versus owners, I will try to summarize things here for everybody's benefit. Sebastian has informed us in the most recent reply that SQL Server 2000 will continue to be supported and that there are no changes planned in the public interface for DNN 5. Scott has asked "Why, How, and What is going to break". Let me answer as follows: Why: Please see significant benefits of owner-schema separation as explained by Microsoft at http://msdn.microsoft.com/en-us/library/ms190387.aspx which is the SQL Server 2005 Books Online article entitled "User-Schema Separation". The benefits of namespace schemas as containers with the convention of the dot character "." marking the container boundaries has proven itself over and over again. And Microsoft in the article clearly explains the distinction between the namespace schema container and the security principals who may own the containers. How: I will personally implement a customized data provider for SQL Server 2005 and higher which will provide the necessary switch enabling optional use of this facility for those who desire. Rhys, you are welcome to continue to criticize the implementation and judge for yourself whether it represents true functionality or what you wish to call "prettiness".  I know that it will offer me true functionality otherwise I would not bother to implement it. What will it break: Nothing. If I succeed in implementing it correctly with the proper diagnostics, failsafes, and switches for selection of options by the administrator, then both the current existing DNN mechanisms should operate or the new mechanism should operate as determined by the administrator's choice for use on any new customized modules. Obviously I cannot make the new mechanism operational on the Core, but I can make it applicable to any new modules separate from the core including my own new modules. When: I will wait until there's a public release of DNN 5 beta before beginning work on this customized data provider, and wait until there's a stable release of DNN 5 before releasing my customized data provider. Anybody interested in working on this with me - whether to discuss requirements or to help with coding - is welcome to contact me.

CT - just wanted to add my two cents to this - remember also that DotNetNuke runs on Oracle too and has since the 2x days. The core (thankfully so) is cognizant of this fact and has to be careful that changes they make doesn't affect the userbase that is currently using Oracle and DNN...
Also, just want to point out, as the author of the oracle dataprovider for DotNetNuke, creating a dataprovider may look like an "easy" task but it takes time and effort. Not saying that you can't do it but just making sure that you're aware that it's not exactly a half an hour effort...

Sanjay