If what ba-insight is saying is correct then I'd say the answer is clear. However, I'd really like to know if MSoft is going to move all those files to a database in that 2004 release.

IMO, I think it should be an option to store in the database or not. Like I said, to intercept the request and compare permissions on that request is easy to do.

Providing an option to store the files in either the database or the filesystem gets my vote.

I think Tom, hit this on the head. there needs to be an option you could set. I personally would not want it a host wide setting but one the could be set on a file by file basis. The host should probably need to be able to assign the ability for an administrator to upload to the db to prevent someone from running away with the allowed DB space. but then once the user has the permission then they could upload files to either location.


Bruce

bhopkins,
Perhaps this needs a little more discussion, because there is more than one goal here due to varied needs. Some of the goals are (correct me if I miss something):
1. Security
2. Web farm support (and other multi access arrangements)
3. Balancing between file system and database size restrictions

1. Security:
Providing the end user with the choice may be ok if you are using DNN in a situation in which you can trust the end user to make the right choice between insecure file system storage and secure database storage. Or perhaps if the ultimate responsibility for security is that of your end users. (Although I still must question the *reason* for providing the end user with this choice?).

For any other situation in which you wish to ensure security you will need to ensure end users do not choose insecure file system storage i.e. prevent the choice. (unless someone develops a secure method of file system storage - see problems already discussed above).

2. Web farm:
It seems that those of us who use web farms (or other multi server/access) who must deal with file syncing issues when the file system is used would also require the option to force the database to be used.

3. Balancing between file system and database size restrictions:
Is a mixed option required, or would those in this situation be able to choose either forced end user file system use or forced end user database use to safely meet size restrictions?

Are there any valid reasons for allowing end users to choose if not for security, web farm or size restriction concerns - which are usually the concern of the host or admin?

Should an option be available at host level or admin level or both? Why?

Sorry for asking so many questions but I don't think I should attempt to answer from other's perspectives as my own use of DNN will be limited to secure intra/extranet and website use with unlimited size restrictions without the use of web farms. Therefore my main personal concern is security (and seeing DNN continue to grow in the most flexible and widely appealing way possible - Go DNN you good thing!).

Note: I have almost completed a standalone Document Database module that is functionally equivalent to the in-built DNN Document module except that documents are stored in the database instead of the file system and module and tab security is checked before viewing or downloading documents. I have developed this to fulfil my immediate needs and for others to use as a basis for their own database file storage modules or DNN enhancements. I would much prefer the core DNN support we are discussing in this thread. I will post more details nearer to completion.

I wasn't really talking about end users as much as I was about the admin of the specific portal. Thats why I said it should be set on the host level. This does not really matter to me as in all my situations at the moment I am both the host and the admin of the portals, but I see a situation coming up that this will be necessary for me.

I plan on developing a student portal where students will be admins, I would not want to give them the ability to upload to the DB, but I would still like to retain the ability in another situation.

Others may want to utlize this type of functionality while some may not need it. If we make it an option then the widest audience will be able to benefit from the enhancment.



Bruce

Document Database module v0.5 for DotNetNuke 1.0.9 now available.

see: http://dotnetnuke.daikyo.com.au

For anyone who is interested in doing some work on database file storage for DNN this may be an easy way for you to start. Also, if you are concerned about the security of your documents stored on the file system, this may serve as an alternative while the DNN document security concerns are addressed more fully.

gsc4,

I think your DbDoc module will come in handy for something I am working on. The possible issue I am running into however is that I am running the 1.0.10 build from dnn.com.

When I loaded the zip, shot off the script and recompiled I then loaded the module onto a tab. I am getting that dreaded red label that is not very descriptive:

Error Loading DesktopModules/DocumentDatabase/Document.ascx

Do you know if the changes that were made in 1.0.10 are not compatible for your module (ver. 0.6)

Thanks much,
Ron