I noticed a number of postings concerning the challenges members were having connecting to a SQL database during the installation of DNN V3.2.2. I was disappointed to learn that these postings often failed to provide the appropriate solution and shocked that I had an easier time finding the solution on another site, but it's a solution nonetheless.

I can summarize its simply with the SQL Server connection string in the web.config file is incorrect. Oops! This is not a SQL Server connection string at all. A small but careless oversight that should have been corrected to say the least. The parameters "Server=; Database=;uid=; pwd=;" should read "Data Source=; Initial Catalog=; user id=; password=;". I've included the regular text below.

I've recently been working with the DotNetNuke 3 betas. Getting the beta working on my local machine was a little tricky, so here are the steps I have found to work. The betas are apparently not shipping with an Access provider, so you'll need MSDE or SQL Server installed for you to tinker at home.

1) Create a directory such as C:\dotnetnuke, or C:\inetpub\wwroot\dotnetnuke. Do not create a subfolder in My Documents, since there may be code access security issues that prevent this location from operating correctly.

2) Grant ASPNET user Modify permissions on this directory.

3) Create a blank database. The docs recommend naming the DB DotNetNuke, but any name will do since you specify it in your connection string.

4) Add the local ASPNET user to the database, with public and dbowner roles.

5) Download the DNN 3 beta.

6) Extract the files into the directory you created in step 1.

7) Open the IIS control panel, and create a new virtual directory mapped to the directory you created in step 1. You must name this virtual directory DotNetNuke.

8) Edit the web.config file so that both SQL connection strings can connect to the database you created in step 3. There are two connection strings, one near the beginning in the appSettings, and one near the end in the SqlDataProvider section. My connection strings read: "Data Source=local;Initial Catalog=DotNetNuke3;trusted_connection=true". Save the web.config.

9) Navigate to http://localhost/dotnetnuke. The portal will create the database and populate the default information.

A common error is the inability of DNN to connect to the database. Make sure the connection string is correct and the permissions are set corectly.

That's interesting hooligannes because the connection string you suggest is valid simply did not work for me. I was attempting to install DNN for development on my PC running Windows XP Pro and was unsuccessful in every attempt to connect to the database. I had also attempted to use the same connection string which you suggested, again unsuccessfully. So while I am interested in the points you raised, and would welcome you to elaborate some more, if I were to apply your suggestion I'd only be back where I was 24 hours ago.

Now I haven't attempted to install this in a production environment but that isn't necessary when I've only begun to learn the DNN product and just need to get it up and running. After nearly a day of trying to install this application I'll accept the path of least resistance if it works. I can't accept credit for this info when it came from Richard Dudley of DotNetJunkies.com.  Incorrect, "misguided" or otherwise, the info that he provided worked when the "correct" information did not. 

Now that I have the correct info I'll be mindful of the points you raised but in the meantime all that matters is that I was finally able to install DNN on my PC. This was my only objective and I'm confident that I'm not alone. In light of your response, my decision not to ask what was already asked a dozen times was the correct one.

I understand your defending DNN turf but there comes a point when a working solution is required as opposed to just spinning ones wheels. I can't argue the technical points you raised because I do not have enough experience with the product. I will correct your assumption pertaining to what I "ignored". Being unaware is very different from ignoring. Ignoring is an intentional act that suggests a conscious decision on the part of the ignoring party to do so.

With that said I'm more curious to learn why your suggestion did not work for me despite the fact that it should work fine.

I did not mean that your information was incorrect, I meant that saying that the format used by DNN was wrong was incorrect. And by 'not asking', I meant that you should've asked if the connection string format used by DNN was wrong, which of course is not and there are thousands of users that can verify this.

I enjoyed the tone of your reply, corteous yet firm; a nice foundation for arguments. I do not want to get into a semantics discussion, yet I will clarify one thing, Ignore is to not knoe something and it is not a crime. I learn most of the things I ignore, reading and listening. I am never afraid to ask cause it takes me to a higher level of knowledge. And the more I learn the more I realise how little I know.

Now, I am not defending DNN's turf because I don't benefit from it and it doesn't need me to do so. What I recommend though is that you investigate why it didn't work the way it was supposed to work. Since DNN follows best practices and decisions by the Core Team are carefully thought out by a pool of talented people, I'd be at least concerned to find out what in my set up is causing me to work differently. I call that learning. So I'd be interested to learn the reasons why the connection string I posted does not work for you. At this time it is a mistery to me. What I can say is that I favor using SQL Authentication but only on my machine where I have absolute control over what's installed and what is used. For customers I use depending on the infrastructure Windows or mixed authentication.