Michael's great tutorial left me with additional questions. Particularly, how to leverage a seperate connection string in the web.config and how to code it in the code-behind.

One thing I learned (and this goes back to Michael's statement of a developers thinking there is an "official" DotNetNuke way of connecting to a database) is if I create a connection string in the web.config I can drag gridviews, formviews, etc onto my page and use that connection string for the SqlDataSource. I am under the assumption that this is not the correct or "official"  way of doing things. It does make the development of the module easier, but I'm a clean freak and want code in the code behind. Hence, the question above. Personally, it is far more beneficial for me to reference the web.config and retrieve the connectionstring as opposed to hard-coding it into the module. It makes it portable in my scenario and allows me to gracefully move from a development environment to production with little or not module modifications.

There is not an "official way" for a SECOND connection string to connect to a database other than the main DotNetNuke database. there IS an "official way" for connecting to the main DotNetNuke database.

However, I think there is a "recommended way" of adding a second connection in this document:

Data Access Guidelines

You can consider storing the connection string in the module setting.  This approach has many advantages:

1.  Each module instance can have it's own database.

2.  All the plumbing to store/retrieve the module settings are already built in.

3.  You don't need to worry about carrying over your web.config settings when upgrading DNN.

4.  If you implement iPortable interface, the module settings (and your connection string) can be easily exported and imported to a new portal.

5.  You can still use your drag and drop VS design method, but substitute the connection string at runtime from the module setting.

6.  If you are security minded, you can encrypt the values before saving.