Hi Rob,
Whew, lots of questions. Let's see if I can address all of them.
1. First of all; you should be aware of the differences between SQL Server Express Edition and the commercial versions. If you only have the Express Edition and want to learn how to develop ASP.NET applications, you may be better off sticking to the Express edition for a while. When you understand more about SQL Server and ASP.NET you can make the move to the commercial versions of SQL Server. At this stage, I think the Express Edition can do pretty much what the commercial versions can do.
Configuring SQL Server is not an easy undertaking. There's a very good reason that DBA's exists.... So, maybe you should do yourself a favor and stick with the autogenerated databases that work against SQL Server Express.
That said, let's look at the rest.
Like I said, at run-time a database is created automatically. This is because, by default *every* website inherits this LocalSqlServer connectionstring that says to attach an empty aspnetdb database to a local SQL Server Express instance. You'll find this connection string in the machine.config file in the folder: C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONF IG (on a default Windows installation)
The machine.config is like the mother of all websites / config files. It provides *default* behaviors for all new websites. However, you can override most of the settings. Basically, that is what Scott's article is showing you: get rid of the default auto-generated Express database, and make the app point to your own database running on SQL Server 2000 or 2005. (Still with me??)
So to answer your first question: it depends. If you changed the web.config file for your application to point to your new database then yes: it will use that database. Like I said, these are run-time features, so at run-time ASP.NET will pick up the change in the web.config file and redirect the provider features (Roles, Membership, Profiles and so on) to this new database.
2) You better not know where the machine.config is... ;) (although I said where it was in the previous section). Basically, you don't want to change stuff in the machine.config file. Instead, override relevant elements in an application's web.config file. Scott's article explains how to do this for the SQL Server database, but there are many other settings you can override.
3) The article on my website (
http://Imar.Spaanjaars.Com/QuickDocId.aspx?quickdoc=395) shows you how to do this. It talks about finding out what account is used, it talks about adding the proper permissions to SQL Server, it talks about configuring the app. Basically, it gives you a step by step explanation of all the things you need to do to make this work. (Notice, I am explicitly not talking about configuring the providers in my article. That's what Scott's blog post is all about).
Maybe you should take a step back, take a deep breath, let things sink in a bit and reread both articles. It might help in giving you a clearer picture; especially with the global information from this post.
But what's important to understand is the different options. Basically, there are three ways to interact with a SQL Server database (at least in the scenario's were dealing with here). Maybe you're confusing some of them...
1. Your *own* code accesses your *own* tables.
All you need is a connection string to your SQL Server. My article explains how this works.
2. Default setup with default provider stuff
You don't need to do anything; everything is created at run-time
3. ASP.NET application with a *different* SQL Server (2000 or 2005) database for the roles. membership etc.
Follow Scott's blog for the setup, the look at mine to see how to tune the security rights.
Basically, that's all there's to it. Of course there's a lot more (or all DBA's would be out of business) but it's at least a general overview of the stuff you'll encounter.
Regarding my book: It's not for absolute beginners, and it's not targeted at SQL users only. Basically, it gives you 12 complete working applications and explains how they work. From Design (class views, UML diagrams, high level overview) to dirty details like the inner working of stored procedures, the new ASP.NET login controls, configuring your own SQL Server database so you don't have to rely on the auto-generated one (what a coincidence) and much more.
Of course I am biased, but I am sure you'll like it....
I think that's it for now. Good luck and have fun reading.....
Imar
---------------------------------------
Imar Spaanjaars
Everyone is unique, except for me.
Author of
ASP.NET 2.0 Instant Results and
Beginning Dreamweaver MX / MX 2004
While typing this post, I was listening to:
My Doorbell by
The White Stripes (Track 3 from the album:
Get Behind Me Satan)
What's This?