I'm sorry Tony - I am afriad don't agree with your comments entirely there - it depends upon the relationship you have with your clients. My clients know the setup and have access to the files they upload themselves and we backup every night, for two weeks, and every two hours we do another backup so, in the worst case scenario if someone wanted their site information we would create the portal locally and export their informaiton to an xls sheet, we don't hand over the sql db to them, and in all my time working with DNN that's worked fine, particularly since generally if you're going to use child portals you would have an idea on what your clients are doing. Or, I could export a template and give to them, it's a backup of their information, and it's not hard to copy and paste a list of users into an xls file for them or have an export tool available (which there are plenty of)
I've got a portal with over 80 childs and out of them abut 55 active clients, and the beauty of DNN is that it is just perfect for this type of environment. Of course we establish the type of client they are before placing them into child portal environments and if my clients want more, then they have the choice of being migrated to another build, or an independent build - it's another project, not just a decision made lightly and usually after discussions, growth experienced by them.
I feel that your comments are suggesting that is not the correct way to do things because I'm putting my clients business at risk or not working in their interest.
TimX5 with his wow guilds has over 8,000 child portals (but I think that's a special sort of crazy too if you ask me) but if they are just doing the same thing and it works, that's great and we need people like him pushing the boundaries and finding how much DNN can and can't do.
And installing a bad module... if you're running a professional business, you don't just install modules on your client sites without some form of testing, so I feel that's a little bit of scaremongering, however, having said that -I have experienced some shockers.... on my server, even one of the most popular modules makes a mess of performance, so it's not allowed on there.
However your situation on the hosting you provide is very different to what I provide so perhaps there are things you experience that I don't, since only two of my resellers have host access, and we have an agreement - that I test and install every single module before it gets put on the server. I have another client who simply sends me the modules to test, or we discuss what he wants to achieve and I come up with a solution/option for him and I handle all his sites so he just goes and sells and does what he does best.
If they want to test, they can get an account with WH4L or other hosters and crash their servers with testing. I only have custom modules running on there that have been developed by people I know of and have a few modules that are NOT allowed on my server due to performance issues that I believe they create.
I would suspect you highly don't recommend it since it doesn't suit hosting companies bottom line to have DotNetNuke used efficiently and that is also understandable since DNN has overhead that other products don't have, and that's the tradeoff - DotNetNuke is less profitable than a celeron box crammed with php sites, that's for sure.
I can assure you that each of my clients using DNN in the correct manner, using the child portal environment do not affect each other, and it provide a cost effective hosting environment for them and they love their sites. But it comes back to know DNN, it's limitations and understanding what is required by the client.
So that's my perspective on this area.
Nina Meiers