views:

203

answers:

4

When creating a new database with SQL Server Express 2005, the database files (.mdf and .ldf) get stored in C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data by default.

However, with the tutorials I've seen for ASP.NET MVC (e.g., Nerd Dinner), it seems to be common practice to keep the database files in the ASP.NET project's App_Data folder.

Questions

  1. Is there any significance to the App_Data folder, or is it just a convenient place to store database files if you happen to use Visual Studio's designer to create a new database?
  2. Will there be any negative repercussions if I don't use or even delete the App_Data folder?

Update

One thing I'm still not getting. If you have a production database on the server, why would you even want to replace this database with what is in App_Data. Wouldn't you normally just want to have update scripts that you run on the production database when you release a new version of the app? Even for initial deployment, I'd rather script database creation than physically copy over the files. Also, with SQL Server (Express) databases, copying is not enough. You have to detach the database to manipulate the files then reattach when you are done.

So, I have to say, the point of App_Data still escapes me. Can someone enlighten me?

+4  A: 

You can delete App_Data without any negative repercussions, but when it exists (by folder name) inside an ASP.NET website then it has the special website power of disallowing direct linking to download its contents - this is a security feature to protect your database from being downloaded directly over the web (e.g. by a web browser) even though it exists in the website. However your application can still access the files in the App_Data folder just as it accesses other website content.

Microsoft states it as:

Note: The content of application folders, except for the App_Themes folder, is not served in response to Web requests, but it can be accessed from application code.

Microsoft describes their special ASP.NET folder structures including App_Data here.

John K
Thanks for your answer...a couple questions though: Are you saying that data stored in `Program Files` *can* be downloaded directly? Or are you only saying that, *if* I want my application code to be able to access these files directly, a safe place to keep them is the App_Data folder? And, finally, *why* would I want my application to access SQL Server database files directly (as opposed to via queries on the server)?
DanM
Data outside of your web applications folder cannot be downloaded directly (unless you somehow explicitly made it available).
Eilon
I modified the answer to make it more clear based on follow-up questions. Just like any other folder on your hard disk, 'Program Files' cannot be downloaded unless it's part of your website served up by the web server, and if file permissions allow it.
John K
The advantage to App_Data is that it's much more portable than something like "Program Files", and can be accessed using relative paths in your web app code.
womp
You use database queries to access the database directly whether it's a file-based database sitting on your hard disk (e.g. in App_Data) or a database running on a server. If your database is running on a server, it isn't a file-based database sitting inside your website.With a file-based database you have the convenience of moving it around with your website; with the App_Data folder you have the additional convenience of not exposing it to the Internet -it would be exposed if sitting inside a regular folder like from where web pages are served from.
John K
Thanks for the clarification. I think some confusion might be resulting from the fact that, while SQL Server Express data *is* stored in files, it's not really file-based the way, say, MS Access is. You still need a server to manipulate the data, and you still need the files to be "attached" before SQL Server can operate on them. Also, what happens once the app is already deployed? When you do updates to the app, you probably aren't going to want to replace the database, you're going to want to update its structure while maintaining the data.
DanM
Thanks for the comment on my update. It sounds like, in my case, App_Data probably won't be of much use, but it's good to know that it's there in case I need it.
DanM
+1  A: 

There is absolutely no need to use the App_Data folder. It's just a convenient place to keep your database files together with your site. The decision to use it or not is more a matter of preference / policy than anything else.

jeroenh
+2  A: 

There are a number of advantages of placing database files in the App_Data folder:

  1. As some have mentioned, that folder is secure from people browsing it directly on the web. This is also true of placing the database in folders outside of your web site, though.
  2. You can "xcopy deploy" your application by copying the entire folder from your local development machine to your hosting web site.
  3. Various components in Visual Studio can offer extra assistance in building your application by having your database files there. For example, you can double-click on a SQL Server Express MDF file and have it automatically open up in Server Explorer so that you can change the database's schema or view its data.
Eilon
+1 Nice answer, thanks. I'm a little confused about #2, though. **Won't this fail due to the SQL Server requirement that you have to detach the database before you can move/delete/replace the database files?** Generally, I script my databases so I can just run the script on the host machine, and everything just works. #2 would seem like more of a help if I were using an Access database, I'm having trouble seeing the value added for SQL Server (Express) databases.
DanM
A: 

yes, when you are simply using an express database which will exist within your webroot it is best to use the app_data folder. The primary reason is that the asp .net isapi implicitly knows not to fulfill any requests for files from this directory. The same goes for the app_code folder. There is no stipulation that you have to but its good practice to be prudent.

You can also store sensitive xml,access dbs and any other data files in here for added security.

I've only ever used it for local development before pointing the web.config at a SQL server instance rather than the db files.

Brian Scott